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METHOD AND STRUCTURE TO DEVELOP A TEST PROGRAM FOR 
SEMICONDUCTOR INTEGRATED CIRCUITS 

5 

CROSS-REFERENCE TO RELATED APPLICATIONS 

[0001] This application is a continuation-in-part application and claims the benefit 

of co-pending U.S. application no. 10/772,434, "Method and Structure to Develop a Test 

10 Program for Semiconductor Integrated Circuits," filed February 6, 2004, which claims the 
benefit of application no. 60/447,839, "Method and Structure to Develop a Test Program 
for Semiconductor Integrated Circuits," filed February 14, 2003; this application also 
claims the benefit of U.S. provisional application no. 60/573,577, "Software 
Development in an Open Architecture Test System" filed May 22, 2004; all of which are 

1 5 assigned to Advantest Corporation and all of which are incorporated herein in their 
entirety by reference. 

BACKGROUND OF THE INVENTION 

Field of Invention 

[0002] The present invention relates to the field of automated test equipment for 

20 semiconductor testing. In particular, the present invention relates to a method for 
developing a test program for a semiconductor test system. 

Description of Related Art 

[0003] A semiconductor test system has a complex system environment having 

multiple devices working together. The test system may include a plurality of controllers, 

25 which control the operation of a plurality of vendor modules and their corresponding 

device-under-tests (DUTs). A test program for a semiconductor test system is required to 
run in the complex system environment. One method of developing such a test program 
is to write test codes directly in a system program language (SPL) such as C++. With this 
method, however, a test engineer is burdened with the complex test system environment. 

30 In particular, the test engineer has to follow a number of complicated system 



WO 2005/114235 PCT7JP2005/009813 

2 

programming rules and to meet the requirements of the system program language in order 
to develop the test program. 

[0004] Another problem with the existing methodology is that errors in the test 

program may not be identified until the test program is compiled in the SPL or until the 
5 test program is run during the testing of a DUT. In addition, it is often difficult and time 
consuming to identify test plan errors in the complex test system environment. Such 
limitations may delay production of the DUT, which could delay product release and lose 
market opportunities. 

[0005] Therefore, there is a need to remove the complexity of system 

10 programming from the development of test plans. In particular, there is a need for 

developing test plans in a language which is closer to the problem domain that the test 
engineer is familiar with, as opposed to a language that introduces the complexity of the 
test system. In addition, there is a need to identify errors in a test plan prior to system 
compilation. An early detection of test plan errors can lead to reduction in development 
1 5 time of the test programs and the DUTs being tested. 

SUMMARY 

[0006] This application describes test program development using object-oriented 

constructs, e.g., C++ objects and classes. In particular, this method is suitable for 
developing test programs for an open architecture tester, such as that described in U.S. 
20 application serial nos. 60/449,622, 1 0/404,002 and 1 0/403,8 1 7, assigned to the assignee of 
the present invention. 

[0007] An embodiment of the present invention provides a method for developing 

a test program by describing test system resources, test system configuration, module 
configuration, test sequence, test plan, test condition, test pattern and timing information 
25 in general-purpose object-oriented, e.g., C/C++, constructs to test a device under test, e.g., 
an IC, on a semiconductor test system, such as automated test equipment (ATE). The 
files containing these descriptions are stored in memory, i.e., a computer-readable 
medium, accessible to the test system or related equipment that uses the files. 

[0008] Describing test system resources may comprise specifying a resource type, 

30 where the resource type is associated with at least one test module for applying a test to 
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the IC, specifying a parameter type associated with the resource type, and specifying a 
parameter of the parameter type. 

[0009] Describing test system configuration may comprise specifying a site 

controller for controlling at least one test module, where each test module applies a test to 
5 the IC, and specifying an input port of a module connection enabler. The test system 
couples the site controller to the module connection enabler at the specified input port, 
. and the module connection enabler couples the site controller to a test module. The 
module connection enabler may be implemented as a switch matrix. 

[0010] Describing module configuration may comprise specifying a module 

10 identifier for specifying a module type, specifying executable code for controlling a test 
module of the module type specified by the module identifer, and specifying a resource 
type associated with the test module. The executable code may take the form of a 
dynamic link library. 

[0011] Describing module configuration may further involve the user specifying a 

slot identifier for specifying an output port of the module connection enabler, where the 
test system couples the test module to the module connection enabler at the output port, 
and the module connection enabler couples the test module to a corresponding site 
controller. The user may also specify a vendor identifier for identifying the provider of 
the test module, and an identifier of the maximum number of resource units available in 
connection with the resource type. The resource type may be, for example, digital tester 
pins and the resource units tester channels. Alternatively, the tester channel resource units 
may also correspond to resource types such as, for example, analog tester pins, RF tester 
pins, power supply pins, digitizer pins, and arbitrary waveform generation pins. An 
indicator relating to which resource units are disabled may also be provided. The 
resource units indicated as disabled may represent defective resource units of the test 
module. 

[0012] ■ Describing test conditions may comprise specifying at least one test 

condition group, specifying a specification set including at least one variable; and 
specifying a selector for selecting an expression to be bound to a variable. Association of 
30 the test condition group with a selector for the specification set defines a test condition. 
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[0013] Describing a test sequence may comprise specifying the order (or flow) in 

which various tests can be applied. 

[0014] Describing test patterns may comprise specifying the test patterns, 

associated voltage and current levels, transitions in signal values, corresponding rise and 
5 fall times and associated timing. 

[0015] A pattern compiler of an embodiment of the invention includes at least one 

module-specific pattern compiler, and an object file manager for directing each module- 
specific compiler to compile both a corresponding module-specific section of a pattern 
source file and a common section of the pattern source file. The common section includes 
10 information accessible to all of the module-specific compilers. An output of the compiler 
includes at least one module-specific pattern data section. Module-specific pattern 
loaders load into corresponding test modules module-specific pattern data from 
corresponding module-specific pattern data sections for execution. 

[0016] The disclosed method for developing a test program separates the 

15 complexity of system programming from the test plan developers by describing the test 
plan in a language that is closer to the problem domain that the test plan is intended to 
address. The method also enables test engineers to identify errors in a test plan at an 
earlier stage of the test program development, which may reduce the development time of 
the test programs and the corresponding DUTs being tested. 

20 [0017] In one embodiment, a method for developing a test program for a 

semiconductor test system includes describing a test plan file in a test program language 
(TPL), where the test plan file describes at least one test of the test program, describing a 
test class file in a system program language (SPL) and a corresponding pre-header file of 
the test class file in the TPL, where the test class file describes an implementation of the at 

25 least one test of the test program, and generating the test program using the test plan file, 
the test class file, and the pre-header file. 



[0018] In another embodiment, a pre-header for generating a test program for a 

semiconductor test system includes a parameters section for specifying at least one 
attribute of the test program, and a template section for inserting source code into a header 
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file of the test program, where at least one attribute of the test program relates to a pattern 
list and a test condition. 

[0019] In yet another embodiment, a method for validating a test program for a 

semiconductor test system includes describing a test plan file in a test program language 
5 (TPL), where the test plan file describes at least one test of the test program, describing a 
pre-header file in the TPL, and validating the test plan file using the pre-header file. 

[0020] In yet another embodiment, a semiconductor test system includes at least 

one test module for applying at least one test to a device-under-test, and a controller for 
receiving a test plan file, a test class file and a corresponding pre-header file of the test 

10 class file, where the test plan file describes the at least one test in a test program language 
(TPL) and the test class file describes an implementation of the at least one test in a 
system program language (SPL). The semiconductor test system further includes means 
for compiling the test plan file and the pre-header file to form a derived test plan file and a 
header file respectively, and means for generating a test program using the test class file, 

1 5 the derived test plan file, and the header file. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0021] The aforementioned features and advantages of the invention as well as 

additional features and advantages thereof will be more clearly understood hereinafter as a 
result of detailed descriptions of embodiments of the invention when taken in conjunction 
20 with the following drawings. 

[0022] Figure 1 illustrates a conventional tester architecture. 

[0023] Figure 2 illustrates a tester architecture according to an embodiment of the 

present invention. . 

[0024] Figure 3 illustrates a tester software architecture according to an 

25 embodiment of the present invention. 

[0025] Figure 4 illustrates a test program compiler according to an embodiment of 

the present invention. 
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[0026] Figure 5 illustrates how different test instances may be derived from a 

single test class according to an embodiment of the present invention. 

[0027] Figure 6 illustrates a pattern compiler according to an embodiment of the 

present invention. 

5 [0028] Figure 7 illustrates a ordered pattern tree example according to an 

embodiment of the present invention. 

[0029] Figure 8 illustrates another ordered pattern tree example according to an 

embodiment of the present invention. 

[0030] Figure 9 illustrates the relationships among files that are required by a test 

1 0 program according to an embodiment of the present invention. 

[0031] Figure 1 0 illustrates waveform generation according to an embodiment of 

the present invention. 

[0032] Figure 1 1 illustrates a mapping used for timing according to an 

embodiment of the present invention. 

15 [0033] Figure 12 illustrates another mapping used for timing according to an 

embodiment of the present invention. 

[0034] Figure 1 3 illustrates a method for developing a test program according to 

an embodiment of the present invention. 

20 DESCRIPTION OF EMBODIMENTS 

[0035] Methods and systems are provided for developing a test program for a 

semiconductor test system. The following descriptions are presented to enable any person 
skilled in the art to make and use the invention. Descriptions of specific embodiments 
and applications are provided only as examples. Various modifications and combinations 
25 of the examples described herein will be readily apparent to those skilled in the art, and 
the general principles defined herein may be applied to other examples and applications 
without departing from the spirit and scope of the invention. Thus, the present invention 
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is not intended to be limited to the examples described and shown, but is to be accorded 
the widest scope consistent with the principles and features disclosed herein. 

[0036] The present invention is generally described in terms of the Open 

architecture test system as disclosed in U.S. application serial nos. 60/449,622, 
5 10/404,002 and 10/403,817 by the same assignee. Those skilled in the art will recognize, 
however, that embodiments of the test program development system and method of the 
present invention are applicable not only to an open tester architecture, but also to fixed 
tester architectures, as well. 

[0037] A description of the open architecture test system may be found in U.S. 

1 0 application no. 1 0/772,327, "Method and Apparatus for Testing Integrated Circuits" 
which claims the benefit of U.S. application no. 60/449,622 by the same assignee. 

[0038] Figure 1 illustrates a generalized architecture of a conventional tester 

showing how a signal is generated and applied to a device-under-test (DUT). Each DUT 
input pin is connected to a driver 2 that applies test data, while each DUT output pin is 
1 5 connected to a comparator 4. In most cases, tri-state driver-comparators are used so that 
each tester pin (channel) can act either as an input pin or as an output pin. The tester pins 
dedicated to a single DUT collectively form a test site that works with an associated 
timing generator 6, waveform generator 8, pattern memory 10, timing data memory 12, 
waveform memory data 14, and block 16 that define the data rate. 

20 [0039] Figure 2 illustrates a system architecture 1 00 according to an embodiment 

of the present invention. A system controller (SysC) 102 is coupled to multiple site 
controllers (SiteCs) 104. The system controller may also be coupled to a network to 
access files. Through a module connection enabler 106, each site controller is coupled to 
control one or more test modules 108 located at a test site 1 10. The module connection 

25 enabler 106 allows reconfiguration of connected hardware modules 108 and also serves as 
a bus for data transfer (for loading pattern data, gathering response data, providing control, 
etc.). Possible hardware implementations include dedicated connections, switch 
connections, bus connections, ring connections, and star connections. The module 
connection enabler 106 may be implemented by a switch matrix, for example. Each test 

30 site 1 1 0 is associated with a DUT 1 12, which is connected to the modules of the 
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corresponding site through a loadboard 114. In one embodiment, a single site controller 
may be connected to multiple DUT sites. 

[0040] The system controller 102 serves as the overall system manager. It 

coordinates the site controller activities, manages system-level parallel test strategies, and 
5 additionally provides for handler/probe controls as well as system-level data-logging and 
error handling support. Depending on the operational setting, the system controller 102 
can be deployed on a CPU that is separate from the operation of site controllers 104. 
Alternatively a common CPU may be shared by the system controller 1 02 and the site 
controllers 104. Similarly, each site controller 104 can be deployed on its own dedicated 
10 CPU (central processing unit), or as a separate process or thread within the same CPU. 

[0041] The system architecture can be conceptually envisioned as the distributed 

system shown in Figure 2 with the understanding that the individual system components 
could also be regarded as logical components of an integrated, monolithic system, and riot 
necessarily as physical components of a distributed system. 

15 [0042] Figure 3 illustrates a software architecture 200 according to an 

embodiment of the present invention. The software architecture 200 represents a 
distributed operating system, having elements for the system controller 220, at least one 
site controller 240, and at least one module 260 in correspondence to related hardware 
system elements 102, 104, 108. In addition to the module 260, the architecture 200 

20 includes a corresponding element for module emulation 280 in software. 

[0043] As an exemplary choice, the development environment for this platform 

can be based on Microsoft Windows. The use of this architecture has side benefits in 
program and support portability (e.g., a field service engineer could connect a laptop 
which runs the tester operating system to perform advanced diagnostics). However, for 
25 large compute-intensive operations (such as test pattern compiles), the relevant software 
can be made as an independent entity capable of running independently to allow job 
scheduling across distributed platforms. Related software tools for batch jobs are thus 
capable of running on multiple platform types. 

[0044] As an exemplary choice, ANSI/ISO standard C++ can be taken as the 

30 native language for the software.Of course, there are a multitude of options available (to 
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provide a layer over the nominal C++ interfaces) that allows a third party to integrate into 
the system with an alternative language of its own choice. 

[0045] Figure 3 illustrates a shading of elements according to their organization 

by nominal source (or collective development as a sub-system) including the tester 
5 operating system , user components 292 (e.g., supplied by a user for test purposes), 

system components 294 (e.g., supplied as software infrastructure for basic connectivity 
and communication), module development components 296 (e.g., supplied by a module 
developer), and external components 298 (e.g., supplied by external sources other than 
module developers). 

1 0 [0046] From the perspective of source-based organization, the tester operating 

system (TOS) interface 290 include: System Controller to Site Controller interfaces 222, 
framework classes 224, Site Controller to Module interfaces 245, framework classes 246, 
predetermined module-level interfaces, backplane communications library 249, chassis 
slot IF (Interface) 262, loadboard hardware IF 264, backplane simulation IF 283, 

1 5 loadboard simulation IF 285, DUT simulation IF 287, Verilog PLI (programming 

language interface) 288 for DUT's Verilog model and C/C++ language support 289 for 
DUT's C/C++ model. 

[0047] User components 292 include: a user test plan 242, user test classes 243, 

hardware loadboard 265, and DUT 266, a DUT Verilog model 293 and a DUT C/C++ 
20 model 291. 

[0048] System components 294 include: system tools 226, communications 

library 230, test classes 244, a backplane driver 250, HW backplane 261, simulation 
framework 281, backplane emulation 282, and loadboard simulation 286. 

[0049] Module-development components 296 include: module commands 

25 implementation 248, module hardware 263, and module emulation 284. 

[0050] External components 298 include external tools 225. 

[0051] The system controller 220 includes interfaces 222 to site controller, 

framework classes 224, system tools 226, external tools 225, and a communications 
library 230. The System Controller software is the primary point of interaction for the 
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user. It provides the gateway to the Site Controllers of the invention, and synchronization 
of the Site Controllers in a multi-site/DUT environment as described in U.S. application 
no. 60/449,622 by the same assignee. User applications and tools, graphical user interface 
(GUI)-based or otherwise, run on the System Controller. The System Controller also may 
5 act as the repository for all Test Plan related information, including Test Plans, test 
patterns and test parameter files. The memory storing these files may be local to the 
system controller or offline, e.g., connected to the system controller through a network. A 
test parameter file contains parameterization data for a Test class in the object oriented 
environment of an embodiment of the invention. 

10 [0052] Third party developers can provide tools in addition to (or as replacements 

for) the standard system tools 226. The standard interfaces 222 on the System Controller 
220 include interfaces that the tools use to access the tester and test objects. The Tools 
(applications) 225, 226 allow interactive and batch control of the test and tester objects. 
The tools include applications for providing automation capabilities (through, for example, 

1 5 the use of SECS/TSEM, etc.) 

[0053] The Communications library 230 residing on the system controller 220 

provides the mechanism to communicate with the Site Controllers 240 in a manner that is 
transparent to user applications and test programs. 

[0054] The Interfaces 222 resident in memory associated with the System 

20 Controller 220 provide open interfaces to the framework objects that execute on the 
System Controller. Included are interfaces allowing the Site Controller-based module 
software to access and retrieve pattern data. Also included are interfaces that applications 
and tools use to access the tester and test objects, as well as scripting interfaces, which 
provide the ability to access and manipulate the tester and test components through a 
25 scripting engine. This allows a common mechanism for interactive, batch and remote 
applications to perform their functions. 

[0055] The Framework Classes 224 associated with the System Controller 220 

provide a mechanism to interact with these above-mentioned objects, providing a 
reference implementation of a standard interface. For example, the site controller 240 of 
30 the invention provides a functional test object. The system controller framework classes 
may provide a corresponding functional test proxy as a remote system controller-based 
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surrogate of the functional test object. The standard functional test interface is thus made 
available to the tools on the system controller 220. The framework classes effectively 
provide an operating system associated with the host system controller. They also 
constitute the software elements that provide the gateway to the Site Controllers, and 
5 provide synchronization of the Site Controllers in a multi-site/DUT environment. This 
layer thus provides an object model in an embodiment of the invention that is suitable for 
manipulating and accessing Site Controllers without needing to deal directly with the 
Communications layer. 

[0056] The site controller 240 hosts a user test plan 242, user test classes 243, 

10 standard test classes 244, standard interfaces 245, site controller framework classes 246, 
module high level command interfaces (i.e., predetermined module-level interfaces 247, 
module commands implementation 248, backplane communications library 249, and a 
backplane driver 250. Preferably most of the testing functionality is handled by the site 
controllers 104/240, thus allowing independent operation of the test sites 1 10. 

1 5 [0057] A Test Plan 242 is written by the user. The plan may be written directly in 

a standard computer language employing object-oriented constructs, such as C++, or 
described in a higher level test programming language to produce C++ code, which can 
then be compiled into the executable test program. For test program development, one 
embodiment of theinvention employs assignee's inventive Test Program Language (TPL) 

20 compiler. Referring to Figure 4, the test program compiler 400 acts in part as a code 

generator including a translator section 402 to translate a test program developer's source 
files 404 describing tests and associated parameters into object-oriented constructs, such 
as C++ code. A compiler section 406, in turn, compiles and links the code into 
executables, e.g., DLLs, to create the test program that may be executed by the tester 

25 system. Although the application of the TPL code generator/translator to test systems is 
novel, please note that code generators are known in the art. Also, the compiler section 
may be a standard C++ compiler known in the art. 

[0058] The test plan creates test objects by using the Framework Classes 246 

and/or standard or user supplied Test Classes 244 associated with the site controllers, 
30 configures the hardware using the Standard Interfaces 245, and defines the test plan flow. 
It also provides any additional logic required during execution of the test plan. The test 
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plan supports some basic services and provides an interface to the services of underlying 
objects, such as debug services (e.g., break-pointing), and access to underlying framework 
and standard classes. 

[0059] The source code input to the test program compiler 400 includes a Test 

5 Plan description file that specifies the objects used in a test plan and their relationships to 
one another. This file is translated to C++ code that is executed on the Site Controller in 
the form of an implementation of a standard interface, which may be denoted 
ITestPlan. This code is packaged into a Windows dynamic link library (DLL), which 
may be loaded onto the Site Controller, The Test Program DLL is generated to have 
10 standard known entry points that the Site Controller software can use to generate and 
return the TestPlan object it contains. The Site Controller software loads the Test 
Program DLL into its process space and uses one of the entry points to create an instance 
of the Test Plan object. Once the Test Plan object has been created, the Site Controller 
software can then execute the test plan. 

1 5 [0060] The Framework classes 246 associated with the site controllers are a set of 

classes and methods that implement common test-related operations. The site controller- 
level framework includes, for example, classes for power supply and pin electronics 
sequencing, setting level and timing conditions, obtaining measurements, and controlling 
test flow. The framework also provides methods for runtime services and debugging. 

20 The framework objects may work through implementing the standard interfaces. For 
example, the implementation of the TesterPin framework class is standardized to 
implement a general tester pin interface that test classes may use to interact with hardware 
module pins. 

[0061] Certain framework objects may be implemented to work with the help of 

25 the module-level interfaces 247 to communicate with the modules. The site controller 
framework classes effectively act as a local operating system supporting each site 
controller. 

[0062] In general more than ninety percent of the program code is data for the 

device test, and the remaining ten percent of the code realizes the test methodology. The 
30 device test data is DUT-dependent (e.g., power supply conditions, signal voltage 
conditions, timing conditions, etc.). The test code consists of methods to load the 
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specified device conditions on to ATE hardware, and also those needed to realize user- 
specified objectives (such as datalogging). The framework of an embodiment of the 
invention provide a hardware-independent test and tester object model that allows the user 
to perform the task of DUT test programming. 

5 [0063] To increase the reusability of test code, such code may be made 

independent of any device-specific data (e.g., pin name, stimulus data, etc.), or device- 
test-specific data (e.g., conditions for DC units, measurement pins, number of target pins, 
name of pattern file, addresses of pattern programs). If code for a test is compiled with 
data of these types, the reusability of the test code would decrease. Therefore, according 
10 to an embodiment of the invention, any device-specific data or device-test-specific data 
may be made available to the test code externally, as inputs during code execution time. 

[0064] In an embodiment of the invention, a Test Class, which is an 

implementation of a standard test interface, denoted here as ITest, realizes the 
separation of test data and code (and hence, the reusability of code) for a particular type of 

1 5 test. Such a test class may be regarded as a "template" for separate instances of itself, 
which differ from each other only on the basis of device-specific and/or device-test- 
specific data. Test classes are specified in the test plan file. Each Test class typically 
implements a specific type of device test or setup for device test. For example, an 
embodiment of the invention may provide a specific implementation of the ITest 

20 interface, for example, FunctionalTest, as the base class for all functional tests for 
DUTs. It provides the basic functionality of setting test conditions, executing patterns, 
and determining the status of the test based on the presence of failed strobes. Other types 
of implementations may include AC and DC test classes, denoted here as 
ACParametricTests and DCParametricTests. 

25 [0065] All test types may provide default implementations of some virtual 

methods (e.g., init ( ) , preExec ( ) , and postExec ( ) ). These methods become the test 
engineer's entry points for overriding default behavior and setting any test-specific 
parameters. However, custom test classes can also be used in test plans. 

[0066] Test classes allow the user to configure class behavior by providing 

30 parameters that are used to specify the options for a particular instance of that test. For 
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example, a Functional Test may take parameters PList and Testconditions, to specify the 
Pattern List to execute, and the Level and Timing conditions for the test, respectively. 
Specifying different values for these parameters (through the use of different "Test" 
blocks in a test plan description file) allows the user to create different instances of a 
Functional Test. Figure 5 illustrates how different test instances may be derived from a 
single test class. These classes may be programmed directly in object-oriented constructs, 
such as C++ code, or designed to allow a test program compiler to take the description of 
the tests and their parameters from a test plan file and generate corresponding C++ code, 
which can be compiled and linked to generate the test program. A Template Library may 
be employed as the general-purpose library of generic algorithms and data structures. 
This library may be visible to a user of the tester, so that the user may, for example, 
modify the implementation of a test class to create a user-defined test class. 

[0067] As to user-developed test classes, an embodiment of the system supports 

integration of such test classes into the framework in that all test classes derive from a 
single test interface, e.g., ITest, so that the framework can manipulate them in the same 
way as the standard set of system test classes. Users are free to incorporate additional 
functionality into their test classes, with the understanding that they have to use custom 
code in their test programs to take advantage of these additional facilities. 

[0068] Each test site 1 10 is dedicated to testing one or more DUTs 1 06, and 

functions through a configurable collection of test modules 112. Each test module 1 12 is 
an entity that performs a particular test task. For example, a test module 1 12 could be a 
DUT power supply, a pin card, an analog card, etc. This modular approach provides a 
high degree of flexibility and configurability. 

[0069] The Module Commands Implementation classes 248 may be provided by 

module hardware vendors, and implement either the module-level interfaces for hardware 
modules, or provide module-specific implementations of standard interfaces, depending 
on the commands implementation method chosen by a vendor. The external interfaces of 
these classes are defined by pre-determined module level interface requirements, and 
backplane communications library requirements. This layer also provides for extension of 
the standard set of test commands, allowing the addition of methods (functions) and data 
elements. 
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[0070] The Backplane Communications Library 249 provides the interface for 

standard communications across the backplane, thereby providing the functions necessary 
to communicate with the modules connected to the test site. This allows vendor-specific 
module software to use a Backplane Driver 250 to communicate with the corresponding 
5 hardware modules. The backplane communications protocol may use a packet based 
format. 

[0071] Tester Pin objects represent physical tester channels and derive from a 

tester pin interface, denoted here as ITesterPin. The software development kit (SDK) of 
an embodiment of the invention provides a default implementation of ITesterPin, which 
10 may be called TesterPin, which is implemented in terms of a predetermined module-level 
interface, IChannel. Vendors are free to make use of TesterPin if they can implement 
their module's functionality in terms of IChannel; otherwise, they must provide an 
implementation of ITesterPin to work with their module. 

[0072] The standard module interface, denoted here as IModule, provided by the 

1 5 tester system of the invention generically represents a vendor's hardware module. 

Vendor-supplied module-specific software for the system may be provided in the form of 
executables such as dynamic link libraries (DLLs). Software for each module-type from a 
vendor may be encapsulated in a single DLL. Each such software module is responsible 
for providing vendor-specific implementations for the module interface commands, which 
20 comprise the API for module software development. 

[0073] There are two aspects of the module interface commands: first, they serve 

as the interface for users to communicate (indirectly) with a particular hardware module 
in the system, and second, they provide the interfaces that third-party developers can take 
advantage of to integrate their own modules into the site controller level framework. 
25 Thus, the module interface commands provided by the framework are divided into two 
types: 

[0074] The first, and most obvious, are those "commands" exposed to the user 

through the framework interfaces. Thus, a tester pin interface (ITesterPin) provides 
methods to get and set level and timing values, while a power supply interface 
30 (IPowerSupply) provides methods for powering up and powering down, for example. 
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[0075] In addition, the framework provides the special category of the 

predetermined module-level interfaces, which can be used to communicate with the 
modules. These are the interfaces used by framework classes (i.e., "standard" 
implementations of framework interfaces) to communicate with vendor modules. 

[0076] However, the use of the second aspect, the module-level interfaces, is 

optional. The advantage of doing so is that vendors may then take advantage of the 
implementations of classes such as ITesterPin and IPowerSupply, etc. while focusing on 
the content of specific messages sent to their hardware by implementing the module-level 
interfaces. If these interfaces are inappropriate to the vendor, however, they may choose 
to provide their custom implementations of the framework interfaces (e.g., vendor 
implementations of ITesterPin, IPowerSupply, etc.). These would then provide the 
custom functionality that is appropriate for their hardware. 

[0077] With this open architecture as background, the test program development 

system of the present invention is further described as follows. Section A below describes 
rules to describe the test environment in which test program will be used; ; section B 
describes the method and rules for test program development; section C specifies the 
method and rules to develop a test plan and how to define the main structure of the test 
program; section D describes how to run a test program on an open architecture test 
system; section E describes a method and rules for test patterns; section F describes rules 
to describe the timing of the test patterns; and section G describes rules for the overall 
tester operation. 

A. Components 

[0078] The test environment comprises a set of files that specify the necessary 

conditions for bringing up the tester, and for preparing it to run a set of tests. The test 

T 

environment preferably includes files for: 

1 . Tester Resource definition: for the specification of the types of tester 
■resources — and supported parameters for such resources — that are 
available in the open architecture test system. 

2. Tester configuration: for the specification of Site Controllers, sites and 
corresponding mappings. 
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3. Module configuration: for specification of the hardware module in each 
site 

4. Pin descriptions: for naming of DUT pins, such as signal pins, power 
supplies, and to describe pin groups, 

5 5. Socket: for the specification of DUT pin-to-tester pin assignments 

6. Pin options: for the specification of special options, or modes, for pins. 

7. Pattern lists: for the specification of test patterns and their sequence. 

8. Patterns: for the specification of test vectors. 

[0079] Of the above, items 1-3 are created by ICF (installation and configuration 

10 files) with information from a CMD (configuration management database), and made 
available at a well-known location, while items 4-8 are user-specified. This section 
provides descriptions for the items 1-6 above; items 7-8 are described in more detail in 
section E. Specific methods and rules are preferably used to develop each of these 
components; these methods and rules will be described in this section with examples. 

15 Al. The Resource Definition 

[0080] Each hardware module provides one or more types of hardware resources 

(resources for short) for use by the test system. The tester Resource Definition is 
preferably used to declare a set of resource names for the available resource types, and a 
set of parameter names and types associated with each particular resource type. For 
20 instance, the resource name dpin is used to refer to digital tester pins. These resources 

have parameters such as VIL (for the input low voltage), VIH (for the input high voltage), 
VOL (for the output low voltage), VOH (for the output high voltage), etc. A resource 
definition file will have the extension ".rsc". Shown below is an example resource 
definition, containing some tester resources: 
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# 

# File Resources.rsc 

# 

Version 0.1.2; 

5 ResourceDefs 

{ 

# digital pins 
dpin 

{ 

10 # Low and High voltages for input pins 

Voltage VIL, VIH; 

# Low and High voltages for output pins 
Voltage VOL, VOH; 

} 

15 # power supplies 

dps 
{ 

# 

# PRE_WAIT specifies the time to wait after voltage 
20 # reached its final value to start pattern 

# generation. The actual time that the system 

# will wait is a small system specified range: 

# PRE_WAIT-delta <= actual <= PRE_WAIT+delta 
# 

25 # PRE_WAIT_MIN is a minimum amount to wait after voltage 

# reached its final value to start pattern generation. 

# It is a system specified range: 

# PRE JWAITJMIN <= actual <= 
PRE_WAIT_MIN+delta 

30 # 

# POSTJWAIT specifies the time to wait after pattern 

# generation ends to shut down the power. The actual 

# time that the system will wait is a small system 

# defined range: 

35 # POST_WAIT-delta <= actual <= POST_WAIT+delta 

# 

# POST_WAIT_MIN specifies the time to wait after pattern 

# generation ends to shut down the power. The actual 

# time that the system will wait is a small system 
40 # defined range: 

# POST_WAIT_MIN <= actual <= 
POST_WAIT_MIN+delta 

# 

Time PRE_WAIT; 
45 Time PRE_WAIT_MIN; 

Time POST_WAIT; 
Time POST_WAiT_MiN; 
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# The voltage. 
Voltage VCC; 

} 

} 

5 [0081] Note that the type of a resource parameter (such as Voltage or Time) is 

preferably a standard engineering unit. Vendors supplying special purpose resources that 
prefer the specification of different parameters should provide their own resource 
definition files. 

Structure for the Resource Definition 
1 0 [0082] Given below is a structure for the resource definition file in accordance 

with a preferred embodiment of the present invention: 

resource-file: 

version-info resource-defs 

version-info: 

1 5 Version version-identifer ; 

resource-defs: 

ResourceDefs { resource-def-list } 

resource-def-list: 
resource-def 

20 resource-def-list resource-def 

resource-def: 

resource-name { resource-params-decl-list } 

resource-params-decl-list 
resource-params-decl 
25 resource-params-decl-list resource-params-decl 

resource-params-decl: 

elementary-type-name resource-param-name-list ; 

resource-param-name-list: 
resource-param-name 
30 resource-param-name-list , resource-param-name 

[0083] Undefined non-terminals above are specified below: 



1 . version-identifier: A sequence of one or more characters from the 
set [0-9a-zA-Z.]. It represents a version number. 
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2. resource-name: A sequence of one or more characters from the set 
[a-zA-Z_0-9], not starting with a digit. It represents the name of a 
resource, such as dpin or dps. 

3. elementary-type-name: A sequence of one or more characters from 
the set [a-zA-Z_0-9], not starting with a digit. It represents the 
name of an elementary type, such as Voltage (cf.). 

4. resource-param-name: A sequence of one or more characters from 
the set [a-zA-Z_0-9], not starting with a digit. It represents the 
name of a resource parameter, such as VIL. 



A2. Tester Configuration 



[0084] The The Tester Configuration is a set of rules that is preferably used to 

list the Site Controllers in a particular system configuration, and the connection of the Site 
Controllers to the Switch Matrix input ports. In the architecture of an embodiment of the 
15 invention, a single Site Controller can be connected to a single switch matrix input port. 
Thus, in this context, the switch matrix connections serve as implicit identifiers for the 
Site Controllers in the system (other configurations are possible). The following is an 
example of a typical tester configuration: 

# 

20 # Tester Configuration, Sys.cfg 

# 

Version 1.2.5; 

SysConfig 

{ 

25 # 

# The first field is the hostname of the Site Controller machine; 

# it can be specified as either a dotted-decimal IP address or a 

# domain-qualified hostname. 

# 

30 # The second field is the switch matrix input port number, which 

# implicitly serves as the identifier for the Site Controller 

# connected to it. 

# 

zeus.olympus.deities.org 2; 
35 127.0.0.2 " 4; 

127.0.0.0 1;#SITEC-1 
127.0.0.3 3; 

} 

[0085] The system configuration for a particular test-floor system is part of the 

40 system profile, and is made available as the system configuration file Sys.cfg. Note that 
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in one embodiment the Site Controller connected to port 1 ("127.0.0.0" in the above 
example) may enjoy special status, in which it alone configures the Switch Matrix. This 
"special" Site Controller will be referred to as SITEC-1. Also note that the site controller 
address in this example is an IP address because the site controllers may be connected to 
5 the system controller by an internal network. Conversely, the system controller may be 
connected to an external network to access files, such as pattern data. 

Structure for the Tester Configuration 

[0086] Given below is a structure for the system configuration file in accordance 

with an embodiment of the present invention: 

1 0 system-config-file : 

version-info system-config 

version-info: 

Version version-identifer ; 

system-config: 

15 SysConfig { site-controller-connection-list } 

site-controller-connection-list: 
site-controller-connection 

site-controller-connection-list site-controller-connection 

site-controller-connection: 
20 site-controller-hostname input-port ; 

site-controller-hostname: 
ip-address 

domain-qualified-hostname 
ip-address: 

25 octet . octet . octet . octet 

domain-qual ified-hostname : 
name 

domain-qualified-hostname . name 
[0087] Undefined non-terminals above are specified below: 

30 1 . version-identifier: A sequence of one or more characters from the 

set [0-9a-zA-Z.]. It represents a version number. 

2. octet: A nonnegative integer from 0 to 255 (in decimal notation). 

3. name: A sequence of one or more characters from the set [a-zA- 
Z_0-9], not starting with a digit. It represents a name segment in a 

35 domain-qualified hostname. 

4. input-port: A nonnegative integer, in decimal notation. 
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A3. The Module Configuration 

[0088] The Module Configuration allows the specification of the physical 

configuration of the tester, e.g., the physical location and type of each module in a 
5 system chassis. This is necessitated by the dynamic nature of the tester bus configuration, 
which allows a mapping of the tester bus address to the physical slot location. This 
information allows a hardware discovery process that occurs at system boot-up time to 
validate the system configuration. Each output port of the Switch Matrix defines a 
physical slot, which is preferably occupied by a single hardware module. Shown below is 
1 0 an example of a module configuration specified in the file Modules. cfg in accordance 
with an embodiment of the invention: 



# 

# Module Configuration File, Modules, cfg 
15 # 

Version 0.0.1; 

ModuleConfig 

{ 

# 

20 # A configuration definition which provides information about 

# the module type that is attached to slots 1-12 and 32-48. 

# Note that a module might provide more than 

# a single type of resource. 

# 

25 Slot 1-12, 32-48 # Switch matrix output ports 

# which use the configuration 

# defined below. 

{ 

VendorlD 1 ; # defined vendor code. 

30 ModuIelD 1; # Vendor-defined id code. 

ModuleDriver modi .dll; # Module software. 

# 

# Resource named dpin specifies channels 

# for digital data. The name dpin is not 

35 # a keyword. It is simply the name of a hardware 

# resource, and is obtained from the resource 

# definition file. 
# 

Resource dpin 
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{ 

MaxAvaiIabIe32; # Resource units 1 .. 32. 

} 

Resource analog 
{ 

MaxAvaiIabIel6; # Resource units 1 .. 16. 



Disabled 1-8; # Disabled resources 1 .. 8. 

# So, enabled ones are 9 .. 16. 



} 

10 } 



# 

# A configuration definition which provides information about 

# the module type that is attached to slots 16-30, 50, and 61-64. 

# 

15 Slot 16-30,50,61-64 

{ 

Resource dpin 
{ 

MaxAvaiIable32; # Max available resource 

20 units. 

Disabled 3, 30-32; # Disabled resources. 

} 

ModuIeDriver "module two.dll"; 
VendorlD 2; 
25 ModuIelD 2; 

} 

# 

# A configuration definition, which provides information about 

# the module type that is attached to slots 65-66. 
30 # 

Slot 65-66 
{ 

ModuIelD 4; # DPS module with 8 supplies. 

ModuIeDriver mod4.dll; 
35 VendorlD 1; 

# 

# Resource type dps specifying resource units for a 

# Device Power Supply 

# 

40 Resource dps 

{ 

MaxAvaiIable4; 
Disabled 1; 

} 

45 } 
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[0089] As mentioned earlier, in one embodiment a slot refers to connector through 

which a hardware module can be connected, such as an output port of the switch matrix. 
Each configuration definition provides information about the module that may be attached 
to one or more slots. The VendorlD specified in a configuration definition is a unique ID 
5 associated with a vendor. The ModulelD refers to a type of module provided by this 
vendor. There may be several instances of the same ModulelD in a tester configuration. 
The ModuleDriver refers to a vendor supplied DLL to service the module. Finally, the 
Resource refers to the units serviced by this module, and provides a name for the resource 
type; the resource name is obtained from the resource definition file. 

10 [0090] The above example describes three configuration blocks in a module 

configuration file. In one implementation, the first configuration block, slots 1-12 and 
32 - 48 are serviced by a module produced by vendor 1. This vendor provides the module, 
the identifier "1" to refer to this module type, and the module driver library to control the 
module. This module can provide two types of resource units, one designated by the 

1 5 resource name "dpin", with preferably a total number of 32 resource units (i.e., 

"channels"), all of which are available, and the other designated by the resource name 
"analog", with a total number of 16 resource units, of which only 9 through 16 are 
available. The second and third configuration blocks are specified in a manner similar to 
the first configuration. 

20 [0091] Note that the provision for allowing channels to be denoted as "disabled" is 

to allow for the identification of defective resource units on modules that are still 
functional otherwise. Note also that a configuration block may have one or more slot 
identifiers. When a block has more than a single slot identifier, then the identified slots 
are said to be cloned. 

25 [0092] The module configuration file, Modules.cfg, is created as part of the 

system profile by the ICM (installation configuration management system) (with test- 
floor-specific information provided by the user), and made available at a well-known 
location. The ICM is a utility that can be local to the test system, e.g., on the system 
controller, or reside elsewhere on the network to which the system controller is connected. 

30 The ICM manages the CMD (configuration management database), and typically updated 
on hardware changes to the system configuration. ICM allows the user to configure the 
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system, e.g., site controllers and modules. The CMD is a database that stores the 
configurations. For actual tester configuration/operation ICM generates the configuration 
files, e.g., module configuration, and other files, and copies them and associated files, 
such as particular module DLLs, onto the tester. 

5 Structure for Module Configuration 

[0093] Below is the module configuration structure in accordance with the 

preferred embodiment: 
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file-contents: 

version-info module-config-def 

version-info: 

Version version-identifier ; 

5 module-config-def: 

ModuleConfig { slot-entry-list } 

slot-entry-list: 
slot-entry 

slot-entry-list slot-entry 

1 0 slot-entry: 

Slot positive-integer-list { slot-info } 

slot-info: 

required-config-list 

required-config-list: 
1 5 required-config 

required-config-list required-config 

required-config: 

VendorlD id-code ; 
ModulelD id-code \ 
20 ModuIeDriver file-name ; 

Resource resource-name { max-spec disabled-spec op i } 

max-spec: 

MaxAvailable positive-integer ; 

disabled-spec: 

25 Disabled positive-integer-list ; 

positive-integer-list: 

positive-integer-list-entry 
positive-integer-list , positive-integer-list-entry 

positive-integer-list-entry: 
30 positive-integer 

positive-integer -number -range 

positive-integer-number-range: 
positive-integer - pos-integer 

[0094] Undefined non-terminals above are described below: 

35 1 . version-identifier: A sequence of one or more characters from the 

set [0-9a-zA-Z.], where the first character must be from the set [0- 
9], 

2. positive-integer: A sequence of one or more characters from the set 
[0-9], not starting with a 0. 

40 3. id-code: A sequence of one or more characters from the set [a-zA- 

Z_0-9]. 
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4. resource-name: A sequence of one or more characters from the set 
[a-zA-Z_0-9], where the first character must be from the set [a- 
zA-Z]. 

[0095] Comments are supported; comments start with the '#' character, and 

extend to the end of the line. 

A4. Pin Descriptions 

[0096] The DUT pin descriptions are described using a Pin Descriptions file. The 

user makes available a description of the DUT pins in a pin description file, which has the 
extension .pin. This plain text file contains, at least the following: a listing of the DUT 
pin names; and initial definitions of named pin groups, which make use of the defined 
DUT pin names ("initial" since they can be subsequently modified or added to, etc., 
programmatically) . 

[0097] The separation of this data specification from the Test Plan description 

allows general reuse of the DUT pin definitions, and allows the pattern compiler to derive 
pin names (required for resolving references to pin names used in vector specifications) 
from the pin description file, without having the process tied to a specific Test Plan. 

[0098] Shown below is an example pin description file: 
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# 

# Pin description file, myDUT.pin. 

# 

# Note that this implicitly imports the resource 

# configuration file,Resources.rsc. 

# 

Version 1.1.3a; 



PinDescription 

{ 

10 Resource dpin 

{ 

AO 
Al 

A2 

15 A3 

A4 



# This syntax expands to the names "ABUSfl]" 
and "ABUS[2]" 

ABUS[1:2]; 



20 A5; 

BBUS[1:8]; 

DIR.; 

CLK; 

Group Grpl 

25 { 



DIR, CLK, AO, Al, A2, A3, A4, BBUS[1 :4] 
} 



WO 2005/114235 PCT7JP2005/009813 

29 

Group Grp2 
{ 

A5, 
# 

5 # The following line will expand to 

FDIR, Al, A2, A4, A5, BBUS[2] ": 

# 

Grpl - CLK - AO - A3 - BBUSfl] - BBUS[3:4] + A5, 
BBUS[5:8] 

10 } 

} 

Resource dps 

{ 

vccl; 

15 vcc2; 

vcc3; 

Group PSG 
{ 

vccl, vcc2 

20 } 

} 

} 

[0099] Note that the DUT pin and pin group definitions are encapsulated within 

resource type blocks, to allow the compiler to correlate pin and pin group definitions with 
25 the allowable parameter settings for Levels, etc. 

[00100] The following points about pin descriptions should be noted: 

1. Pin groups and pins share the same namespace and have global (i.e., Test Plan) 
scope. One of the consequences of the global scoping of these names is that 
pins and pin groups cannot use duplicated names, even when declared in 

30 different resource blocks. 

2. At least one Resource definition is required in the pin description file. 

3. At least one pin name should be defined in each resource. 

4. Pin and group names are required to be unique within resource boundaries. 

5. The same pin or group name can be defined for two or more resources. 
35 However, duplicates within the same resource are ignored. 

6. All pin names and group names that appear in a group definition should have 
been already defined within that resource. 
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7. Group definitions, if given, should have at least one pin name or group name 
(i.e., a group definition cannot be empty). 

8. A pin group definition can include a reference to a previously-defined pin 
group. 

5 9. A pin group definition can include set operations such as addition and 

subtraction of previously defined pins and/or pin groups. 



Structure for the Pin Descriptions 

[00101] Given below is the structure for the pin descriptions in accordance with the 

1 0 preferred embodiment of the present invention: 

pin-description-file: 

version-info pin-description 

version-info: 

Version version-identifer ; 

15 pin-description: 

PinDescription { resource-pins-def-list } 

resource-pins-def-list: 
resource-pins-def 

resource-pins-def-list resource-pins-def 

20 resource-pins-def: 

Resource resource-name {pin-or-pin-group-def-list} 

pin-or-pin-group-def-list: 
pin-or-pin-group-def 

pin-or-pin-group-def-list pin-or-pin-group-def 

25 pindef-or-pin-groupdef: 

pin-def; 
pin-group-def 

pin-def: 
pin-name 

30 pin-name [ index : index ] 

pin-group-def: 

Group pin-group-name {pin-group-def-item-list } 

pin-group-def-item-list: 
pin-def 

3 5 pin-group-def-item-list , pin-def 
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[00102] Undefined non-terminals above are specified below: 

1. version-identifier: A sequence of one or more characters from the 
set [0-9a-zA-Z.]. It represents a version number. 

2. resource-name: A sequence of one or more characters from the set 
[a-zA-Z_0-9] not starting with a digit. It represents the name of a 
resource, such as dpin or dps. 

3. pin-name: A sequence of one or more characters from the set [a- 
zA-Z_0-9] not starting with a digit. It represents the name of a pin 
AO. 

4. pin-group-name: A sequence of one or more characters from the set 
[a-zA-Z_0-9] not starting with a digit. It represents the name of a 
pin group ABUS. 

5. index: A nonnegative integer. It represents the lower bound or an 
upper bound on a group of related pins. 

A5. The Socket 

[00103] The Socket specifies the mapping between DUT pin names and physical 
tester pin (channel) assignments (the physical tester channel numbers are defined in the 
module configuration file). Note that different Sockets can be used to support different 
DUT packages and different load board configurations, etc. For a multi-DUT system, the 
Socket definitions for DUT/channel assignments can support "cloning" of a basic Socket 
to multiple sites. However, different Sockets (i.e., different physical mappings for the 
same logical pins) should respect site module partitions. Thus, in addition to providing 
DUT pin to tester channel assignments, the socket also effectively defines the site 
partitioning. A Socket file could thus contain definitions for several individual site 
sockets. Shown below is a sample socket file defining three DUT sites: 

Version 1.1.3 

SocketDef 
{ 

DUTType CHIP3 
{ 
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Pi ii Description dutP3.pin; # The pin description file for CHIP3 

DUT 2 # Uses the full-specification syntax 
{ 

SiteController 1; # Switch Matrix input port 

Resource dpin 
{ 

# 

# The CLK pin is assigned to resource dpin, 

# slot 2, resource unit (channel) 13. 

# 

CLK 2.13; 
# 

# The DIR pin is assigned to resource dpin, 

# slot 5, resource unit 15. 
DIR 5.15; 

# 

# The following statement will be expanded to 

# BBUS[7] 5.4 

# BBUS[6] 5.5 

# BBUS[5] 5.6 

# 

# So for example, the pin sequence BBUS[7], BBUS[6], 

# BBUS[5] is assigned to the same slot 5, and to 

# resource units 4, 5 and 6 respectively. 
# 

BBUS[7:5] 5.[4:6]; 

BBUS[1:4] 7.[21:18]; 
BBUS[8j 9.16; 

} 

Resource dps 
{ 

# 

# The VI pin is assigned to resource dps, 

# slot 1, resource unit (channel) 1. 
# 

VCC1 1.1; 

# 

# The VCC2 pin is assigned to resource dps, 

# slot 1, resource unit (channel) 2. 
# 

VCC2 1.2; 

} 

} # End DUT 2 

DUT 1 # This is "cloned" from DUT 2 above 
{ 
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SiteController 1; # Same Site Controller as for DUT 2 

Resource dpin 
{ 

SlotOffset 1 ; # Offset value for slots 

5 } 

Resource dps 

{ 

SlotOffset 10; # Offset value for slots 

} 

10 # 

# The offset syntax above indicates that the slot/resource 

# unit assignments are "cloned" from the first DUT defined 

# for this DUTType, i.e., DUT 2, with the slots offset by 

# the SlotOffset values. 
15 # 

# Looking at the definition of dpin resource units for 

# DUT 2, CLK is bound to slot 2. Hence, for the present 

# DUT, CLK is bound to slot 2 + 1=3. 
# 

20 # Some of the new bindings in effect due to the offset 

# assignments are shown in the table below: 
# 

# 

# Pin Resource RUnit Slot 
25 # 

# CLK dpin 13 2 + 1 = 

3 

# DIR dpin 15 5+1 = 

6 

30 # BBUS[8] dpin 16 9+ 1 = 10 

# VCC1 dps 1 1 + 10=11 

# VCC2 dps 2 1 + 10 = 11 

# 

} # End DUT 1 

35 } # End DUTType CHIP3 

DUTType 74LS245 
{ 

PinDescription dutLS.pin; 

DUT 3 disabled # This DUT site is disabled, and will be 
40 ignored 

{ 
} 

} # End DUTType 74LS245 
45 } # End SocketDef 
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[00104] The following points about a Socket file should be noted: 

1 . The Socket file uses information from both module configuration 
file, and the user's pin description files for the given DUT types 

5 (see specification for PinDescription in the example above). The 

module configuration information is made implicitly available to 
the Socket file compiler. The socket file compiler is a sub-part of 
the pattern compiler that reads and analyzes the socket DUT name 
to tester channel mapping, and the module configuration and pin 
10 description files to set up the mapping of tester pins to DUT pins 

used by the pattern compiler. 

2. At least one DUT site definition per DUT type is required, and it 
must use the full-specification syntax, as opposed to the SlotOffset 
syntax. If more than one DUT site definition is provided for the 

1 5 same DUT type, the first one must use the full-specification syntax. 

3. Each subsequent DUT site definition (for the same DUT type) may 
use either the full-specification syntax or the SlotOffset syntax, but 
not both. This allows individual sites to deviate from a standard 
pattern (due to, for example, inoperative channels). 

20 4. The bindings derived from the SlotOffset syntax are defined 

relative to the first site defined for that DUT type (which uses the 
full-specification syntax). 

5 . DUT sites do not need to be declared in the actual physical order. 
This allows a case where the first (physical) site deviates from the 

25 pattern. 

6. The DUT site IDs are required to be unique across the entire Socket 
(i.e., across all DUT types defined therein). 

7. At least one resource definition is required per DUT site definition. 

8. The site definitions must be used in conjunction with the module 
30 configuration to determine if the test configuration is single- 

site/single-DUT or single-site/multi-DUT. 
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9. In all cases, the Socket file should specify a set of DUT channel 
mappings which are consistent with the pin description file and the 
module configuration file. 

10. In some cases, it will be desirable to allow the Socket definition to 
5 specify that one or more DUT channels are disconnected from the 

tester (for example, by designating the assigned physical channel as 
one with the special ID "0.0"). In this case, these DUT channels 
may be used and referenced in the context of the test program. 
Operations on such channels will result in system warnings (but not 
10 errors.). At load time, pattern data for disconnected channels will 

be discarded. 

Structure for the Socket 

[00105] Below is the structure for the module configuration in accordance with a 
1 5 preferred embodiment of the present invention: 

socket-file: 

version-info socket-def 

version-info: 

20 Version version-identifier ; 

' socket-def: 

SocketDef { device-specific-socket-def-list } 

25 device-speciftc-socket-def-list: 

device-specific-socket-def 

device-specific-socket-def-lisl device-specific-socket-defi 

device-specific-socket-def: 
30 DUTType DUT-type-name { pin-description-file dut-info-list } 

pin-description-file: 

PinDesc pin-description-file-name ; 

35 dut-info-list: 

dut-info 

dut-info-list dut-info 
dut-info: 

40 DUT dut-id { site-controller-input-port resource-info-list } 
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site-controller-input-port: 

SiteController switch-matrix-input-port-number ; 

5 resource-info-list: 

resource-info 

resource-info-list resource-info 
resource-info: 

10 Resource resource-name { resource-item-unit-assignment-list } 

resource-item-unit-assignment-list: 
resource-item-unit-assignment 

resource-item-unit-assignment-list resource-item-unit-assignment 

15 

resource-item-unit-assignment: 

resource-item-name slot-number . resource-unit ; 
resource-item-name [ resource-item-index ] slot-number . resource- 
unit-index ; 

20 resource-item-name [ resource-item-index-range ] \ 

slot-number . [ resource-unit-index-range ] ; 



25 



resource-item-index-range: 

resource-item-index : resource-item-index 

resource-unit-index-range: 

resource-unit-index : resource-unit-index 
[00106] Undefined non-terminals above are specified below: 

1 . version-identifier: A sequence of one or more characters from 
30 the set [0-9a-zA-Z.]. It represents a version number. 

2. DUT-type-name: A sequence of one or more characters from 
the set [0-9a-zA-Z.], where the first character must not be from the set 
[0-9]. It represents a type of DUT, such as CHIP3. 

3. pin-description-file-name: The simple name of a file, not 
35 including its directory name, but including all extensions. The 

filename is of the syntax recognized by the host operating system, and 
allows blanks and other characters if enclosed in quotes. 

4. switch-matrix-input-port-number: A nonnegative integer in 
decimal notation to represent the port number of the input port 

40 connected to the Site Controller. 
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5. dut-id: A nonnegative integer in decimal notation to identify an 
instance of a DUT. 

6. resource-name: A sequence of one or more characters from the 
set [0-9a-zA-Z.], where the first character must not be a digit. It 

5 represents the name of a resource defined in a resource file. 

7. resource-item-name: A sequence of one or more characters 
from the set [0-9a-zA-Z.], where the first character must not be a digit. 
It represents the name of a resource unit, such as a pin or a pin group. 

8. resource-item-index: A nonnegative integer in decimal notation 
1 0 that represents a particular member of a group of resource items. 

When in the context of a resource-item-index-range it represents the 
lower or upper bound of a contiguous sequence of resource item group. 

9. resource-unit-index: A nonnegative integer in decimal notation 
that represents a particular member of a group of resource units 

15 (channels). When in the context of a resource-unit-index-range it 

represents the lower or upper bound of a contiguous sequence of 
resource unit group. 



A6. Pins 

20 [00107] Note that in addition to logical pin name to physical channel mappings (as 
provided by the Socket), several attributes can be used for specifying the tester resources. 
For example, options might be used to define particular hardware configurations for 
channels, which may be test-specific, vendor-specific, and/or test system-specific. These 
will be described using the Pin Mode Options, and made available via a Pin Mode 

25 Options file. 

[00108] . A Pin Mode Option definition would support the configuration of special 
options or modes for a tester channel. This could, for example, be used to select and 
configure channel multiplexing. It is preferred that the Pin Mode Option only be used as 
part of a Test Plan initialization flow, since it might require significant channel 
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configuration. The Pin Option syntax supports vendor-defined options. An example is 
shown below. 

PinModeOptions 

{ 

5 clock IN double; 

aO OUT single; 

}; 

10 Test Environment Configuration 

[00109] As pointed out earlier, the resource definition file (Resources. rsc), the 
system configuration file (Sys.cfg) and the module configuration file (Modules.cfg) are 
preferably made available at a "well-known" location. This "well-known" location is the 
directory specified by the value of the system environment variable 
1 5 Tester_ACTIVE_CONFIGS . For example, if the value of Tester_ACTIVE_CONFIGS is 
the directory F:\Tester_SYS\configs, the system will expect the following files to be 
present: 

F:\Tester_SYS\configs\Resources.rsc 
F:\Tester_SYS\configs\Sys.cfg 
20 F:\Tester_SYS\configs\Modules.cfg 

[00110] During installation, the Installation and Configuration Management system 
(ICM) residing on the host computer will preferably set the value of 
Tester_ACTIVE_CONFIGS. Every time the ICM creates a new version of one of the 
25 above files, it will place the new version in the location pointed to by 

Tester_ACTIVE_CONFIGS . Note that in addition to the above three files, other system 
configuration files such as the simulation configuration file are also placed in the location 
pointed to by Tester_ACTIVE_CONFIGS 

30 B. Rules for Test Program Development 
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[00111] One of the two principal end-user oriented components of the tester system 

is the test environment. The other component is the programming facility that the tester 
makes available for the end user (i.e., test engineer and test class developers). 

[001 12] The principal component of the programming environment is the test plan. 
5 The test plan uses test classes (which are different implementations of a test interface 
denoted Test), which realize the separation of test data and code for particular types of 
tests. 

[001 13] The plan may be written directly as a C++ test program, or described in a 
test plan description file, which is processed by a Test Program Generator (translator 402) 
10 to produce object-oriented code, such as C++ code. The generated C++ code can then be 
compiled into the executable test program. The data required for populating a test class 
instance, such as levels, timings, etc., are specified by the user in the test plan description 
file. 

[00114] A test program contains a set of user written files that specify details for 
15 running a test on a device. An embodiment of the invention includes sets of rules that 
permit a user to write these files using C++ constructs. 

[00115] One of the requirements according to the embodiment of the invention is to 
follow the modularity of the open architecture test system., A modular development 
permits users to write individual components dealing with different aspects of the test, and 
20 then permits these components to be mixed and matched in various ways to yield a 

complete test program. A test program in accordance with the preferred embodiment of 
the present invention comprises a set of files as follows: 

files *.usrv for user variables and constants; 
files *.spec for specification sets; 
25 files *.lvl for levels; 
files *.tim for timings; 
files *.tcg for test condition groups; 
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files *.bdefs for bin definitions; 

files *.ph for a pre-header, files for custom functions and test classes. 
files *.ctyp for custom types; 
files *.cvar for custom variables; and 
5 files *.tpl for test plans. 

[00116] The file extensions above are a recommended convention facilitating 
categorization of files. A single test program will preferably comprise a single test plan 
file, and the files it imports. An "import" refers to other files with data that is either 

1 0 directly referenced by the importer (the file that specifies the import), or is imported by 

some other file directly referenced by the importer. The test plan file could define globals, 
flows, and other such objects within it, or it could import this information from other files. 
These rules allows any of the above components to be either in their own individual files, 
or directly inlined into a test plan file. Note that the test plan is similar in concept to a C- 

15 language main() function. 

Test Program Features 

User Variables and Constants, 
Specification Set, 
Levels, 
20 Timings, 

Test Conditions 
Bin Definition 
Pre-Headers 
Custom Types 
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[00117] 



Test program identifiers preferably start with an upper or lower case 



5 alphabetical character, and can subsequently have any number of alphabetical, numerical, 
or underscore ( _ ) characters. It has several keywords which are provided in the 
description given below. These keywords are visually identified in code in this document 
using a bold font, such as Version. Keywords are reserved, and preferably not be used as 
identifiers. There are several special symbols such as {, }, (, ), :, and others which are 
10 described below. 

Elaboration of Test Objects 

[00118] An import of a test description file enables the importing file to refer to 
names of objects made available by the imported file. This allows the importing file to 
reference the objects named by the imported file. Consider a socket file aaa.soc that 
15 imports a pin description file xxx.pin. There could be another bbb.soc file that also 
imports xxx.pin. However, neither of these imports cause the objects described by 
xxx.pin to come into existence. They merely reference objects that are already assumed 



20 where the Test Plan file is fundamentally different. In an analogy to C, it would be a file 
with a main() routine in it. An "Import" statement in test plan file will elaborate these 
objects, that is, cause these objects to come into existence. The test plan mickey.tpl 
shown below causes the objects in xxx.pin and aaa.soc to be elaborated: 



to exist. 



[00119] 



The question arises: when do such objects come into existence? This is 



25 



# File for Mickey's TestPlan 
Version 3.4.5; 



# 



# These import statements will actually cause the 

# objects to come into existence: 



30 



# 



Import xxx.pin; # Elaborates pin and pin-group objects 
Import aaa.soc; # Elaborates site socket map objects 
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# Other imports as necessary 

Flow Flowl 
{ 

5 

} 

[00120] An import of xxx.pin in the test plan causes all the pin and pin group 

objects declared in xxx.pin to be elaborated. This is described as follows: "the file 
xxx.pin is elaborated". It is not necessary for a Test Plan to directly import all the files 
1 0 that need to be elaborated. A file x is imported by a file y if either of the two statements 
below is true: 

1 . y has an import statement that names x; or 

2. x is imported by z, and y has an import statement naming z. 

1 5 [00121] When a test program is compiled, it will elaborate all the objects in the 
files that are imported by the test plan. The set of files imported by a test plan are 
topologically sorted to yield an order in which the files are elaborated. The set of files 
imported by a test plan is referred to as the import closure of the test plan. If the import 
closure of a test plan cannot be topologically sorted, then there must be an imports cycle. 

20 Such a situation is erroneous, and will be rejected by the compiler. 

User Variables and Constants 

[00122] Global variables and constants will be defined using the User Variables 
and Constants. . Constants are objects whose value is bound at compile time, and cannot 
be changed. The maximum integer value, for instance, would be a constant. On the other 
25 hand, the expression bound to variables can' change at runtime via an API. 

Integer, 

Unsignedlnteger, 

Double, 

String, 



30 



Voltage in Volts (V), 
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VoltageSlew in Volts per Second (VPS), 
Current in Amps (A), 
Power in Watts (W), 
Time in Seconds (S), 
5 Length in Meters (M), 
Frequency in Hertz (Hz), 
Resistance in Ohms (Ohms), and 
Capacitance in Farads (F). 



10 [00123] The types Integer, Unsignedlnteger, Double, and String are referred to as 
Basic Types. The Basic Types have no measurement units. The Elementary Types which 
are not basic types are a Double, with an associated measurement unit and a scale. The 
scaling symbols are common engineering scaling symbols: 

p (pico) for 10-12, as in pF (pico-farad) 
15 n (nano) for 10-9, as in nS (nano-second) 
u (micro) for 10-6, as in uS (micro-second) 
m (milli) for 10-3, as in mV (milli-amp) 
k (kilo) for 10+3, as in kOhm (kilo-ohm) 
M (mega) for 10+6, as in MHz (mega-hertz) 

20 G (giga) for 10+9, as in GHz (giga-hertz) 

[00124] A separate file with user variables and constants will have the 
extension .usrv. Below is an example of a file with some global constants. An example 
of a file with some variables is given later. 
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# 

# File limits .usrv 

# 

5 Version 1.0.0; 

# 

# This UserVars collection declaration declares a set of 

# globally available variables and constants. 
10 # 

UserVars 

{ 

# Some constant Integer global s used in various places. 
Const Integer Maxlnteger = 2147483647; 

1 5 Const Integer Minlnteger = -2147483648; 

# Smallest value such that 1 .0 + Epsilon != 1 .0 
Const Double Epsilon = 2.2204460492503 1 3 1 e-0 1 6; 

20 # Some important constants related to Double 

Const Double MaxDouble = 1.7976931 348623 158e+308; 
Const Double MinDouble = - MaxDouble; 
Const Double ZeroPlus = 2.2250738585072014e-308; 
Const Double ZeroMinus = - ZeroPlus; 

25 

} 

[00125] The set of UserVars declared above are considered definitions of the 
variable on the left of the As a result, a single occurrence of the definition of a 
30 variable or constant is preferred, and it should be initialized. 

[00126] As mentioned earlier, constants should not be changed once they are 
defined. The expression bound to a constant can involve previously defined constants and 
literal values. Variables, on the other hand, can be changed via an API. The expression 
bound to a variable can involve previously defined variables, constants and literal values. 

35 [00127] Each variable is bound to an expression object which is maintained at 
runtime. This provides the capability of changing the expression associated with a 
variable at runtime, and then.re-evaluating all the variables. The expression object is a 
parsed form of the right hand side of a variable or constant definition. In one embodiment, 
no facility is provided for the changing of constants at runtime. Their value is preferably 

40 fixed at compile time. 
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[00128] Any number of such files with globals can exist in the import closure of a 
test plan. While the above globals file is a set of numeric limits, here is a set of 
engineering globals using engineering measurement units, and some random user 
variables: 



10 



# 

# File myvars.usrv 
# 



Version 0.1; 



# This declares a UserVars collection of some engineering 

# globals. 

# 

15 UserVars My Vars 

{ 

# Engineering quantities. 

Const Voltage VInLow = 0.0; # 0 Volts 

Const Voltage VInHigh = 5.0; #5 Volts 

20 Const Voltage VOutLow = 400.0 mV; # 400 milliVolts 

Const Voltage VOutHigh =5.1; #5.1 Volts 

Const Time DeltaT = 2.0E-9; # 2 nanoseconds 

Const Time ClkTick = 1.0ns; # 1 nanosecond 
Const Resistance Rl 0 = 1 0.0 kOhms; # 1 0 kilo Ohms 

25 

# Some variables are declared below. 

Current ILow = 1 .0 raA; # 1 milliAmp 

Current IHigh = 2.0 mA; # 2 milliAmp 

Power PLow = ILow * VInLow; # Low power value 

30 Power PHigh = IHigh * VInHigh; # High power value 

# 

# An array of low values for all A bus pins. 

# The vil for AO will be in ABusVil[0], for Al 
35 # in ABusVil [ 1 ] , and so on. 

# 

Voltage ABusVil[8] = {1.0, 1.2, Others = 1.5}; 

} 

40 [00129] The compiler preferably checks that units and types match up. Note that 
since a Voltage times a Current yields a Power, the equations for PLow and PHigh above 
will compile. However, a statement such as the following will typically not compile: 



# 

# Does not compile because a Current and a Voltage cannot be added 
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# to yield a Power. 

# 

Power Pxxx = IHigh + VInHigh; 
[00130] The compiler will allow certain automatic type conversions: 

5 Power Pxxx = 2; # Set the power to 2.0 watts 

Integer Y = 3.6; # Y gets assigned 3 
Power Pyyy = Y; # Pyyy gets assigned 3.0 watts 
Double Z = Pyyy; # Pyyy gets converted to a unitless Double 

[00131] Explict type conversion to Double, Unsignedlnteger and Integer is also 

10 permitted: 

Power Pxxx = 3.5; 

# Explicit type conversion is allowed, but not required. 

# X becomes 3.5 

1 5 Double X = Double(Pxxx); # X becomes 3.5 

Integer Y = Integer(Pxxx); # Y becomes 3 

[00132] Conversion between unrelated types is also possible, by converting to an 

intermediate basic type: 

Power Pxxx = 3.5; 

20 

# Explicit type conversion is required. 

Length L = DoubIe(Pxxx); # L becomes 3.5 meters 
Voltage V = Integer(Pxxx); # V becomes 3.0 Volts. 

[00133] The TestPlan object provides a UserVars class which is a collection that 

25 contains names and their associated expressions, values, and types. User variables can go 

into a Default User Variables Collection, or into a Named User Variables Collection. 

The UserVars declarations in the example above, which have no specified name, go into 

the default collection. However, it is possible to explicitly name a collection as follows: 

# Declare X and Y in the MyVars UserVars collection. 
30 UserVars MyVars 

{ 

Integer X = 2.0; 
# 

# Refers to the above X, and to the globally 
35 # available Maxlnteger from the default 

# UserVars collection. 

# 

Integer Y = Maxlnteger - X; 

} 
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# Declare X, Yl and Y2 in the YourVars UserVars collection: 

UserVars YourVars 

{ 

Integer X = 3.0; 

5 # Refers to the X from MyVars. 

Integer Yl = Maxlnteger - MyVars.X; 

# Refers to the X declared above. 
Integer Y2 = Maxlnteger - X; 

} 

1 0 # More variables being added to the MyVars collection 

UserVars MyVars 

{ 

# 

# Refers to X and Y from the earlier declaration 
15 # of MyVars. 

# 

Integer Z = X + Y; 

} 

[00134] Name resolution within a UserVars collection proceeds as follows: 

20 If a name is qualified — i.e., a name comprises two segments separated by a dot 

— then the variable comes from a named user variables collection, named by the 
segment that precedes the dot. So, MyVars.X above refers to the X in the MyVars 
collection. The name " UserVars" can be used to explicitly denote the default 
user variables collection. 

25 [00135] If the name is not qualified, and there is a constant or variable of the same 
name in the present collection, then the name resolves to that constant or variable. 

[00136] Otherwise, the name resolves to a constant or variable in the default user 
variables collection. 

[00137] Evaluation of a block of definitions in a UserVars collection can be 
30 thought of happening sequentially, from the first definition to the last. This may require 
each variable being defined before it is used. 

[00138] Furthermore, there could be several blocks of definitions for a UserVars 
collection, each of which are defining several variables. All of these blocks of definitions 
can be thought of as being evaluated in declaration order in the test plan, and then the 
35 variables of each block are also checked in declaration order. 
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[00139] Finally, there could be several UserVars collections, each of which define 

variables over several blocks of definitions. All of the variables again can be thought of 
as being initialized in declaration order. Thus, in the above example, the evaluation order 
would be: MyVars.X, MyVars.Y, YourVars.X, YourVars.Yl, YourVars.Y2, MyVars.Z. 

5 [00140] When a UserVars collection uses a variable from another collection, it 
preferably uses just the raw value of the variable. No dependency information is 
maintained between collections. Thus, dependency based re-evaluation can be limited to 
a single collection. 

[00141] Each user variables collection refers to an instance of a C++ UserVars 

10 class. The default object of the C++ UserVars class is named "JJserVars". Variables in 
an UserVars declaration that is unnamed are from the default user variables collection, 
and are added to this default object. Variables in a named user variables collection are 
added to an object of the C++ UserVars class having that name. In the above example, 
the "MyVars" C++ object will end up having the variables X, Y and Z. 

1 5 C++ for User Variables 

[00142] User variables are implemented as a collection of »-tuples having the name 
string, a const/var boolean, the type as an enumerated value and the expression as an 
expression tree. The expression of a name can be set by a call: 

enum ElemenaryType {UnsignedlntegerT, IntegerT, 
20 DoubleT, VoltageT, . . . } ; 

Status setExpression(const String& name, 
const bool isConst, 
const elementaryType, 
const Expression& expression); 

25 [00143] The type Expression is a type that is a parsed form of the text 

corresponding to the right hand side of an assignment. There will be a globally available 

instance of UserVars. For example, the set of user variables in limits.usrv (cf. page) is 

implemented by the set of calls shown below: 

_UserVars.setExpression("MaxInteger", true, IntegerT, 
30 ~ ' Expression^ 147483647)); 

_UserVars.setExpression("MinInteger", true, IntegerT, 

Exprcssion(-2 147483648)); 
_UserVars.setExpression("Epsilon", true, DoubleT, 

Expression(2.2204460492503 1 3 1 e-0 1 6)); 
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_UserVars.setExpression("MaxDouble", true, DoubleT, 

Expression(1.7976931348623158e+308)); 
_UserVars.setExpression("MinDouble", true, DoubleT, 

Expression("- MaxDouble")); 
5 _UserVars.setExpression("ZeroPlus", true, DoubleT, 

Expression(2.2250738585072014e-308)); 
_UserVars.setExpression("ZeroMinus", true, DoubleT, 

Expression("- ZeroPlus")); 

[00144] Below are the C++ statements that would be executed for the variables 
1 0 declared in myvars.usrv: 



myVars.setExpression("VInLow", true, VoltageT, 
Expression(0.0)); 

myVars.setExpression("VInHigh", true, VoltageT, 
Expression(5.0)); 

15 myVars.setExpression("DeltaT", true, TimeT, 

Expression(2.0E-9)); 
myVars.setExpression("ClkTick", true, TimeT, 

Expression(l .OE-9)); 
myVars.setExpression("R10", true, ResistanceT, 
20 Expression(10.0E+3)); 

myVars.setExpression("ILow", false, CurrentT, 

Expression(l .0E-3)); 
myVars.setExpression("IHigh", false, CurrentT, 

Expression(2 . 0E-3 )) ; 
25 myVars.setExpression("PLow", false, PowerT, 

Expression("ILow * VInLow")); 
myVars.setExpression("PHigh", false, PowerT, 

Expression("IHigh * VInHigh")); 
myVars.setExpression("ABusVil[0]", false, VoltageT, 
30 Expression(l.O)); 

myVars.setExpression("ABusVil[l]", false, VoltageT, 

Expression(L2)); 
myVars.setExpression("ABusVil[2]", false, VoltageT, 

Expression(1.5)); 

35 myVars.setExpression("ABusVil[3]", false, VoltageT, 

Expression(1.5)); 
myVars.setExpression("ABusVil[4]", false, VoltageT, 

Expression(l.S)); 
myVars.setExpression("ABusVil[5]", false, VoltageT, 
40 Expression( 1.5)); 

myVars.setExpression("ABusVil[6]", false, VoltageT, 

Expression(1.5)); 
myVars.setExpression("ABusVil[7]", false, VoltageT, 

Expression(1.5)); 
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[00145] In the code above, the Expression class preferably has constructors that 
represent the parsed form of the expression. Expression has several constructors, 
including one that takes a string literal and parses it, and another that takes a string literal 
to use just as a string literal. These are distinguished by additional parameters which are 
5 not specified above for the sake of readability. 

[00146] User variables in the default user variables collection will be managed by 
the _UserVars object of class UserVars. User variables in a named user variables 
collection Xxx will be managed by a UserVars object named Xxx. 

Runtime API for UserVars 

1 0 [00147] The C++ UserVars class that contains these names and expressions exports 
an application programming interface (API) to evaluate and modify these values at 
runtime. Modification of the expressions associated with UserVars also addresses the 
issue of when the UserVars will be reevaluated, and what the impact of the evaluation will 
be. 

1 5 [00148] Consider first the issue of when the re-evaluation of UserVars as a result of 
a change should be triggered. If it is triggered immediately upon making a change to the 
expression, then the user would not be able to make a series of related changes prior to 
triggering the re-evaluation. Consequently, re-evalutation is triggered by an explicit call 
by the user. 

20 [00149] The impact of reevaluation can be considered next. There are three kinds 
of re-evaluation that are available in accordance with the preferred embodiment: 

[00150] UserVars Collection Re-evaluation is re-evaluation limited to a single 
UserVars collection. The semantics of this operation is to re-evaluate all the variables of 
this collection once again. 

25 [00151] UserVars Targeted Re-evaluation is re-evaluation limited to a change to 
the expression bound to a single name. This would enable the user to change the 
expression of a single name, and cause the re-evaluation of the collection to take place, 
taking into consideration only this particular change. 
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[00152] User Vars Global Re-evaluation is re-evaluation of all UserVars 

collections. This basically triggers a re-evaluation of all the UserVars collections in 
declaration order and is quite costly. 

[00153] All of the above re-evaluations will re-evaluate dependent objects such as 
5 Levels, Timings, etc. after re-evaluating the UserVars. Dependent objects will have a 
dirty bit that represents that it needs re-evaluation. Any time a UserVars collection is 
programmatically changed, it will also set the dirty bit on all dependent objects. This will 
trigger re-evaluation of the dependent objects. 

[00154] In summary, named UserVars collections help contain the re-evaluation 

10 impact problem. Re-evaluation is normally limited to a single collection. A simple way 
of using UserVars would be to only use the default UserVars collection. That way, the 
ripple effect of making a change can happen to all UserVars. This ripple effect can be 
limited by having several named UserVars collections. 

[00155] Multiple collections can refer to variables from one another, but the values 
15 bound to the variables are bound at time of use. No dependency is maintained between 
UserVars collections. 

[00156] For each elementary type Xxx (JJnsignedlnteger, Current, Voltage, etc.), a 
method to get the value: 

Status getXxxValue(const String& name, Xxx& value) const; 

20 Note that there is no method to directly set a value, it is done through the call to set the 
expression, followed by a call to reevaIuateCollection(). 

[00157] Methods to get and set the expression. The setExpressionQ call can also be 
used to define a new variable which was not hitherto defined. 

enum elementaryType 
25 { 

UnsignedlntegerT, IntegerT, DoubleT, VoltageT, ... 

}; 

Status getExpression(const String& name, 

Expression& expression) const; 
30 Status setExpression(const String& name, 

const bool isConst, 
const elementaryType, 
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const Expression& expression); 
[00158] The setExpression() call can fail if the expression results in a circular 
dependency. For instance if the following two calls were made, the second call would fail 
with a circular dependency failure 

5 setExpression("X", true, IntegerT, Expression("Y+l")); 

setExpression("Y", true, IntegerT, Expression("X+l")); 

This is because the values bound to names are equations and are not assignments. When 

the value of a variable is changed, a method is provided to re-evaluate all the directly and 

indirectly dependent names. Equations such as the above pair result in a circular 

1 0 dependency which is not permitted. 

[00159] Note that this API does not typically support unsolicited re-evaluation. A 
call to setExpressionO may not automatically cause the variable, and all other variables 
that depend on it, to be re-evaluated. The values bound to all variables will stay 
unchanged until a call to reevaluateCollection() (below) occurs. 

1 5 [00160] A method to determine if a particular name is a constant : 

Status getIsConst(const String& name, bool& isConst); 

[00161] A method to get the type: 

enum Elementary Type 

{ 

20 UnsignedlntegerT, IntegerT, DoubleT, VoltageT, ... 

}; 

Status getType(const String& name, 

Elementary Type& elementaryType) const; 

[00162] The UserVars Collection Re-evaluation method. 
25 Status reevaluateCollection(); 

[00163] The class will maintain equations related to all the variables, and their 
dependencies. When this method is called, all of the variables will get re-evaluated. 

[00164] The UserVars Targeted Re-evaluation method. 

Status reevaluateTargeted(const String& var); 
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[00165] The class will maintain equations related to all the variables, and their 
dependencies. When this method is called, the named variable, and all of its dependents 
will get re-evaluated. 



The UserVars Global Re-evaluation method. 
5 static Status reevaluateAHCollections(); 

[00166] The class will maintain equations related to all the variables, and their 
dependencies. When this method is called, reevaluateCollection() is called on all 
UserVars collections in an unspecified order. 

[00167] A method to determine if a particular name is defined: 

10 Status getIsDefined(const String& name, bool& isDefined) const; 

[00168] A method to determine all the user variables currently defined: 
Status getNames(StringList& names) const; 

[00169] A method to delete a presently defined variable: 
Status deleteName(const String& name); 

15 [00170] This operation will fail if the name is used in expressions involving other 
variables. 



A method to get the list of variables and constants that depend on a given variable or 
constant: 

Status getDependents(const String& name, StringList& 
20 dependents); 

Specification Sets 

[00171] The Specification Set is used to supply a collection of variables which can 

take on values based on a Selector. For example, consider the following Specification Set 
that uses selectors Minnie, Mickey, Goofy and Daisy: 

25 # 

# File Aaa.spec 

# 
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Version 1.0; 

Import Limits.usrv; 

5 SpecificationSet Aaa(Minnie, Mickey, Goofy, Daisy) 

{ 

Double xxx = 1.0, 2.0, 3.0, 4.0; 
Integer yyy = 10, 20, 30, 40; 
Integer zzz = Maxlnteger — xxx, 
1 0 Maxlnteger - xxx - 1 , 

Maxlnteger - xxx - 2, 

Maxlnteger - xxx; 

# The following declaration associates a single 
1 5 # value, which will be chosen regardless of the 

# selector. It is equivalent to: 

# Integer www = yyy + zzz, yyy + zzz, yyy + zzz, yyy + zzz 
Integer www = yyy + zzz; 

} 

20 [00172] The above Specification Set with the selector Goofy will make the 

following associations: 

xxx = 3.0; 

yyy = 30; 

zzz = Maxlnteger - xxx - 2; 
25 www = yyy + zzz; 

[00173] The operation of setting the selector on a specification set will be discussed 
later, when Tests are described. 

[00174] Syntactically, a specification set a is list of selectors (Minnie, Mickey, 
Goofy and Daisy in the example above), along with a list of variable definitions (xxx, yyy, 
30 zzz and www in the example above). The definition of a variable involves a list of 

expressions that is either as long as the list of selectors, or comprises a single expression. 

[00175] Conceptually a specification set can be thought of as a matrix of 
expressions, whose columns are the Selectors, whose rows are the variables and whose 
entries are expressions. A particular selector (column) binds each variable (row) to a 
35 specific expression (entry). If the list has a single expression, it represents a row with the 
expression replicated as many times as there are selectors. 



[00176] Specification sets can appear in two separate contexts. They could be 
separately declared in a .spec file, in which case they appear as shown above. These are 
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named specification sets. Otherwise, local specification sets can be declared within a Test 
Condition Group. In such a declaration, the specification set will not be provided with a 
name. It will be a local specification set, of significance only to the enclosing test 
condition group. 

[00177] Named specification sets can be modeled after the named user variables 
collection. The above specification set can be modeled as a UserVars collection named 
Aaa, which will have expressions for xxx[Minnie], xxx[Mickey], xxx[Goofy], xxx [Daisy], 
yyy [Minnie], and so on. When a particular selector (say Mickey) is chosen in the context 
of a test, the values of xxx, yyy and zzz are obtained from the variable name and the 
specification set name. 

[00178] A test condition group can have at most one specification set, which is 
either a local specification set, or a reference to a named specification set. Local 
specification sets appear only in the context of a test condition group, and have no 
explicitly specified name. Such a specification set has an implicit name that is defined by 
the name of the enclosing test condition group. To resolve a name in a test condition 
group at a point where several specification sets and several UserVars collections are 
visible, the following rules are applied: 

1 . If the name is qualified, it must be resolved in a named user variables 
collection. 

2. If the name is not qualified, the name is resolved in either a local 
specification set, if it is declared in the test condition group, or in the 
named specification set, if one is referenced in the test condition group. 

3. If the name is not resolved by the earlier rules, it is resolved in the default 
user variables collection. 

[00179] To illustrate these rules, consider the following example using Test 
Conditions Groups (to be described later) 

Version 1.2.3; 

Import limits.usrv; # Picks up the limits UserVars file above. 
Import aaa.spec; # Picks up the Specification Set AAA above. 

TestConditionGroup TCG1 

{ 

SpecificationSet(Min, Max, Typ) 
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{ 

vcc = 4.9, 5.1, 5.0; 

} 

# Rule 1: Resolution in a named user variables collection. 

# A reference to MyVars.VInLow refers to VInLow from MyVars. 

# Rule 2: Resolution in a local specification set. 

# A reference to "vcc" here will resolve in the context 

# of the local specification set above. 

# Rule 3: Resolution in default user variables collection. 

# A reference to "Maxlnteger" here will resolve to limits .usrv. 

# EiTor: Resolution of xxx 

# A reference to xxx does not resolve because it is neither in 

# the local specification set, nor in limits.usrv. 

# Error: Resolution of Aaa.xxx 

# Looks for a named UserVars collection named Aaa. The named 

# specification set does not qualify. 

} 

TestConditionGroup TCG2 
{ 

SpecificationSet Aaa; # References the imported specification set 

# Rule 1 : Resolution in a named user variables collection. 

# A reference to MyVars.VInLow refers to VInLow from MyVars. 

# Rule 2: Resolution in a named specification set. 

# A reference to "xxx" here will resolve in the context 

# of the local specification set Aaa above. 

# Rule 3: Resolution in default user variables collection. 

# A reference to "Maxlnteger" here will resolve to limits.usrv. 

# Error: Resolution of vcc 

# A reference to vcc does not resolve because it is neither in 

# the named specification set Aaa, nor in limits.usrv. 

# Error: Resolution of Aaa.xxx 

# Looks for a named UserVars collection named Aaa. The named 

# specification set does not qualify. 

} 

[00180] Resolution of a name in a specification set (rule above) requires that a 
selector of the set be enabled at the time the name resolution is required. This will be 
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enforced by the fact that the test condition group will be referenced in a Test by 
specifying a selector. 

C++ for Specification Sets 

[00181] Using the above rules, Specification sets can be implemented by the C++ 
5 Specifications et class. The Specifications et class has essentially the same API as the 
UserVars class, except for an extra String parameter for the selector. Consequently, this 
API is not described in detail. 

[00182] All named specification sets are preferably associated with a C++ object of 
that name. A local specification set in the context of a test condition group will have a 
1 0 name that is unique to that test condition group. It is illegal to refer to a variable of a local 
specification set outside the context of the test condition group that it is defined in. 

Levels 

[00183] The Levels are used to specify parameters of pins and pin groups. It is a 
collection of declarations of the form: 

1 5 <pin-or-pin-group-name> 

{ 

<pin-param-l> = xxx; 
<pin-param-2> = yyy; 

20 } 

[00184] Such a declaration specifies the setting of the various parameters of the 
named pin or pin-group. For example, such a statement could be used to set the VIL 
values for all pins in the InputPins group, as shown in the example below: 



25 # 

# File CHIPlevels.lvl 
# 



Version 1.0; 

30 

Import CHIP3resources.rsc; 
Import CHIP3pins.pin; 

Levels CHIP3Levels 

35 { 

# 



58 



# Specifies pin-parameters for various pins and 

# pin groups using globals and values from 

# the specification set. 

# 

# The order of specification is significant. 

# Pin parameters will be set in order from 

# first to last in this Levels section, and 

# from first to last for each pin or pin-group 

# subsection. 
# 

# From the imported pin description file CHIP3pins.pin, 

# the InPins group is in the "dpin" resource. From the 

# imported resource definition file CHIP3resources.rsc, 

# the "dps" resource has parameters named VIL and VIH, 
# 

InPins { VIL = v_il; VIH = v_ih + 1.0; } 



# The following statement requires a delay of 10 uS after 

# the call to set the InPins levels. Actual delay will be 

# a small system defined range around 10.0E-6: 

# 10.0E-6 - delta <= actual <= 10.0E-6 + delta 
Delay 10.0E-6; 

# 

# For the OutPins, the levels for the parameters 

# VOL and VOH are specified. 

# 

OutPins { VOL = v_ol / 2.0; VOH = v_oh; } 

# The clock pin will have special values. 
Clock { VOL = 0.0; VOH = v_ih / 2.0; } 

# A Delay of 10 uS after the call to set Clock levels. 

# This is a minimum delay, that is guaranteed to be for 

# at least 10.0 uS, though it may be a little more: 

# 1 0.0E-6 <= actual <= 1 0.0E-6 + delta 
MinDelay 10.0 uS; 

# 

# The PowerPins group is in the "dps" resource. Pins of this 

# pin group have special parameters: 

# PREWAIT specifies the time to wait after voltage 

# reached its final value to start pattern 

# generation. Actual wait time will be a small 

# system defined range around PRE_ WAIT (see) 

# POST_WAIT specifies the time to wait after pattern 

# generation ends to shut down the power. Actual 

# wait time will be a small system defined range 
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# around PREWAIT (see). 

# 

PowerPins 
{ 

5 PRE_WAIT = 10.0 ms; 

POST_WAIT=10.0 ms; 

# VCC reaches its final value of 2.0 V from its 

# present value in a ramp with a Voltage Slew Rate 
1 0 # of ±.01 Volts per Second. 

VCC = Slew(0.01, 2.0 V); 

} 

} 



Levels CHIP4Levels 
{ 

} 

20 [00185] As seen above, each Levels block is preferably made up of a number of 
levels items, each of which specifies parameters for a pin or pin group. Each levels item 
can specify a number of resource parameters. The runtime semantics for the setting of 
these levels values is as follows: 

[00186] The levels items of the Levels block are processed in declaration order. 
25 Any pin that occurs in more than one levels item will get processed multiple numbers of 
times. Multiple specification of values for a single parameter should be maintained and 
applied in specification order. 

[00187] The resource parameters in a levels item are processed in the order they are 
specified. 

30 [00188] The Delay statements cause the process of setting levels to pause for 

approximately the indicated duration, prior to setting the next group of levels. The actual 
wait time may be in a small system defined range around the specified delay. So if the 
delay was t seconds, the actual delay would satisfy: 
t - At <= actual-wait <= t + At 

35 [00189] The Delay statements divide up the Levels specification into a number of 
subsequences, each of which will require separate Test Condition Memory settings for 
processing. 
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[00190] The MinDelay statements cause the process of setting levels to pause for at 

least the specified duration prior to setting the next group of levels. The actual wait time 
may be in a small system defined range with a minimum value of the specified minimum 
delay. So if the minimum delay was t seconds, the actual delay would satisfy: 
5 t <= actual-wait <= t + At 

[00191] The MinDelay statements divide up the Levels specification into a number 
of subsequences, each of which will require separate Test Condition Memory settings for 
processing. 

[00192] Each pin or pin-group name is specified in exactly one resource in a pin 
10 description file (suffix .pin), and therefore has a certain set of viable resource parameters 
specified in the resource file (suffix .rsc). All the parameters named must be from among 
this set of viable resource parameters, and must be of the same elementary type as the 
expression used to set their value. Information about the names and types of resource 
parameters comes from the resource file. 

1 5 [00193] The resource file Resources.rsc is implicitly imported, providing tester 
with the names and types for parameters of standard resources such as dpin, and dps. 

[00194] Resource parameters are assigned expressions that can use UserVars, and 
values from named specification sets or a currently visible local specification set. 

[00195] Dps pin resources have special parameters PRE_WAIT and POST_WAIT. 
20 The PRE_WAIT parameter specifies the time that needs to elapse from the time the power 
pin has reached its destination voltage to the time pattern generation can start. The 
POST_WAIT parameter specifies the time that needs to elapse from the time pattern 
generation has stopped to the time the power pin shuts off. 

[00196] Dps pins also specify how the voltage parameter reaches its final value. 
25 They could specify it simply by an equation, as all other pin parameters. In that case the 
value will be reached as the hardware allows it. They could also specify it using a Slew 
statement. A Slew statement specifies that the power supply voltage reaches its final 
value from the initial value in a ramp with a specified absolute Voltage Slew Rate. 

C++ for Levels 
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[00197] With above rules, a C++ Levels object can be written that supports the 

following operations: 

There is an operation 

Status setParameter(const String& pinOrPinGroupName, 
5 const String& parameterName, 

ElementaryType elementary Type, 
const Expression& Expression); 

[00198] This operation binds an expression to a parameter of a pin or a pin group. 

For instance, the dpin.InPins VIH value is set by: 

10 setParameterC'InPins", "VIH", VoltageT, 

Expression("v_ih + 1 .0"); 

[00199] This operation will be called several times for all the declarations in the 

Levels object. 

There is an operation 
15 Status assignLevels(const String& selector); 

which will go through and issue all the pre-determined module level 
interfaces to assign all the levels of parameters in specification order, as 
described earlier. The selector parameter is used to resolve names in the 
expressions according to the rules specified earlier. 

20 

Test Condition Groups 

[00200] The Test Condition Group Sub-language packages together the description 
of specifications, timings and levels. Timing objects are often specified using parameters. 
Parameters can be used in timings to specify leading and trailing edges of various pulses. 
25 Likewise, Levels can be parameterized by specifying maximum, minimum and typical 
values of various voltage levels. A Test Condition Group (TCG) object lumps together 
the specifications and the instantiation of Timings and Levels based on these specifications. 



30 



[00201] A TestConditionGroup declaration contains an optional Specifications et. 
The Specifications et declaration may be an Mined (and unnamed) local Specifications et, 
or it may be a reference to a named SpecificationSet declared elsewhere. The optional 
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Specifications et declaration in a TCG declaration is followed by at least one Levels or 
Timings declaration. It can have both Levels and a Timings, in any order. However, it is 
disallowed from having more than one Levels and Timings declaration. These restrictions 
are syntactically enforced. 

5 [00202] A specification set declaration in a TCG is identical to the specification set 
declared separately, except that it does not have a name. Its name is implicitly the name 
of the enclosing TCG. The Timings declaration comprises a single declaration of a 
Timings object from a specified timings file. Here is an example of a file with a test 
condition group: 

10 # 

# File myTestConditionGroups.tcg 

# 

Version 0.1; 

15 

Import CHIPlevels.lvl; 
Import edges. spec; 
Import timing 1 .tim; 
Import timing2.tim; 

20 

TestConditionGroup TCG1 

{ 

# This Local SpecificationSet uses user-defined selectors 

# "min", "max" and "typ". Any number of selectors with any 
25 # user defined names is allowed. 

# 

# The specification set specifies a table giving values for 

# variables that can be used in expressions to initialize 

# timings and levels. The specification set below defines 
30 # values for variables as per the following table: 

# min max typ 

# v_cc 2.9 3.1 3.0 

# v_ih vlnHigh + 0.0 vlnHigh + 0.2 vlnHigh + 0. 1 

# v_il vlnLow + O.O vInLow + 0.2 vInLow + 0.1 
35 # ... 

# A reference such as "vlnHigh" must be previously defined 

# in a block of UserVars. 
# 

# Thus, if the "max" selector was selected in a functional 
40 # test, then the "max" column of values would be bound to 

# the variables, setting v_cc to 3. 1, v_ih to vInHigh+2.0 

# and so on. 
# 
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# Note that this is a local specification set, and has no 

# name. 

SpecificationSet(min, max, typ) 
{ 

5 # Minimum, Maximum and Typical specifications for 

# voltages. 

Voltage vcc = 2.9, 3.1, 3.0; 
Voltage v_ih = vlnHigh + 0.0, 
vlnHigh + 0.2, 

10 vlnHigh + 0.1; 

Voltage v_il = vlnLow + 0.0, 
vlnLow + 0.2, 
vInLow+ 0.1; 

15 # Minimum, Maximum and Typical specifications for 

# leading and trailing timing edges. The base 

# value of 1.0E-6 uS corresponds to 1 picosecond, 

# and is given as an example of using scientific 

# notation for numbers along with units. 
20 Time tje = 1 .OE-6 uS, 

1.0E-6uS + 4.0* DeltaT, 
1 .OE-6 uS + 2.0 *DeltaT; 
Time t_te = 30ns, 

30ns + 4.0 * DeltaT, 

25 30ns + 2.0 * DeltaT; 

} 

# Refers to the CHIP3Levels imported earlier. It 

# is one of possibly many levels objects that have been 
30 # imported from the above file. 

Levels CHIP3Levels; 

# Refers to file timingl .tim containing the single 

# timing Timingl . The filename should be quoted if 
35 # it has whitespace characters in it. 

Timings Timingl; 

} 

# Another test condition group 
40 TestConditionGroup TCG2 

{ 

# ClockAndDataEdgesSpecs is a specification set which 

# is available in the edges. specs file. Assume it has 

# the following declaration: 

45 # SpecificationSet ClockAndDataEdgesSpecs(min, max, typ) 

# { 

# Time clockje = 10.00 uS, 10.02 uS, 10.01 uS; 

# Time clockje = 20.00 uS, 20.02 uS, 20.01 uS; 

# Time dataje = 10.0 uS, 10.2 uS, 10.1 uS; 
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# Time dataje = 30.0 uS, 30.2 uS, 30. 1 uS; 

# } 

# A SpecificationSet reference to this named set is below: 
SpecificationSet ClockAndDataEdgesSpecs; 

5 

# An Mined levels declaration. Since the associated 

# specification set (above) does not have variables such 

# as VInLow, VInHigh, VOutLow and VOutHigh, they must 

# resolve in the default UserVars collection. 
10 Levels 

{ 

InPins { VIL = VInLow; VIH = VInHigh +1.0;} 
OutPins { VOL = VOutLow / 2.0; VOH = VOutHigh; } 

} 

15 

# This Timing is from the file "timing2.tim". The timings 

# will need the leading and trailing edge timings for clock 

# and data as specified in the above specification set. 
Timings Timing2; 

20 } 

[00203] In the above example, the test condition group TCG1 describes a 
specification set with three selectors named "min", "typ" and "max". There can be any 
number of distinct selectors. Within the body of the specification set, variables v_il 5 v_ih, 
t_le and t_te are initialized with triples of values, corresponding to the selectors. So in the 

25 above example, an instance of TCG1 with the selector "min" will bind the variable y_il 
with the first numeric value, (vlnputLow+O.O). It bears repetition that the selectors for a 
specification set are user defined, and any number of them is allowed. The only 
requirement is that: 

[00204] The selectors of a specification set be unique identifiers. 

30 [00205] Each value specified in the specification set is associated with an array of 
values that exactly the same number of elements as the set of selectors. Picking the z' th 
selector will cause each value to be bound to the i th value of its associated vector of values. 

[00206] Subsequent to the specification set in the TCG, there could be a Levels 
declaration or a Timings declaration or both. The Levels declaration is used to set levels 
35 for various pin parameters. The variables identified in the specification set will be used to 
set these levels, permitting a dynamic binding of different actual values for pin parameters 
based on the selector used to initialize the TCG. 
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[00207] To exemplify this, consider a Test that enables the selector "min". 

Referring to the specification set CHIP3Levels given on page, the pin parameter "VIH" 
for pins in the InPins group will be initialized to the expression (v_ih + 1.0) by the 
declaration: 

5 InPins { VIL = v_il; VIH = v_ih +1.0;} 

[00208] This resolves to (VInHigh + 0.0 + 1 .0) when the selector "min" is enabled. 
Likewise, the Timings object can be initialized based on the selected values of the 
specification set variables. It is not necessary to have both a Timings and a Levels 
declaration. Either can be present by itself, or both in any order, as illustrated by the 
10 following example: 

# 



# File LevelsOnlyAndTimingsOnly.tcg 

# 



15 Version 0.1; 

# A Levels-only Test Condition Group. 
TestConditionGroup LevelsOnlyTCG 

{ 

20 SpecificationSet(Min, Max, Typ) 

{ 

Voltage v_il = 0.0, 0.2, 0.1; 
Voltage y_ih = 3.9, 4.1, 4.0; 

} 

25 

# An inlined levels declaration. Since the associated 

# specification set (above) does not have variables such 

# as VInLow, VInHigh, VOutLow and VOutHigh, they must 

# resolve in the default UserVars collection. 
30 Levels 

{ 

InPins { VIL = yjl; VIH = v_ih +1.0;} 
OutPins { VOL = vjl / 2.0; VOH = v_ih; } 

} 

35 } 



# A Timings-only Test Condition Group 
TestConditionGroup TimingsOnlyTCG 
40 { 

SpecifIcationSet(Min, Max, Typ) 

{ 
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Time tje = 0.9E-3, 1.1E-3, 1.0E-3; 



} 



Timings Timing2; 



[00209] Note, however, there should not be more than one Timings and more than 
one Levels in a TCG. Thus, in summary, there should be at least one of Timings or 
Levels, and at most one of each. 

Test Conditions 



[00210] A TestCondition object ties a TCG to a specific Selector. Once a TCG has 
been declared as shown above, it is possible to declare TestCondition objects as shown 
below: 

TestCondition TCMin 



TestConditionGroup = TCG1; 
Selector = min; 



TestCondition TCTyp 

TestConditionGroup = TCG1; 
Selector = typ; 



TestCondition TCMax 

TestConditionGroup = TCG1; 
Selector = max; 



[00211] These Test Conditions would be instantiated in a Test Plan as follows: 

# 

# Declare a FunctionalTest "MyFunctionalTest" that refers to three 

# Test Condition Group instances. 

# 

Test FunctionalTest MyFunctionalTest 
{ 

# Specify the Pattern List 
PList = patlAlist; 

# Any number of TestConditions can be specified: 
TestCondition = TCMin; 

TestCondition = TCMax; 
TestCondition = TCTyp; 
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} 

Name Resolution in TCGs (test condition groups) 

[00212] Resolution of names in a test condition group was discussed earlier. 
However, these rules bear repetition, and are given below again: 

5 1 . If the name is qualified (cf. page), it must be resolved in a named user 

variables collection. 

2. If the name is not qualified, the name is resolved in either a local 

specification set, if it is declared in the test condition group, or in the 
named specification set, if one is referenced in the test condition group. 

10 3 . If the name is not resolved by the earlier rules, it is resolved in the default 

user variables collection. 

TCG Runtime 

[00213] Test condition groups have the following runtime semantics: 

[00214] A Test (such as a FunctionalTest) will reference a TCG with a particular 
1 5 selector from its SpecificationSet, using an instantiated TestCondition. This selector will 
bind each variable in the SpecificationSet to its value associated with the chosen selector. 
This binding of variables to their values will then be used to determine Levels and 
Timings. 

[00215] Parameter Levels in a TestConditionGroup are preferably set sequentially, 
20 in the order of presentation in the Levels block. So in the CHIP3Levels block, the order 
in which parameter levels would be set is as follows (notation: <resource- 
name>.<resource-parameter>): 

InpufPins.VIL, 
InputPins.VIH, 
25 OutputPins.VIL, 
OutputPins.VIH, 



Clock. VOL, 
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Clock.VOH. 

[00216] This sequencing order enables the test writer to control the explicit power 
sequencing of power supplies. Furthermore, if a levels item occurs twice, naming the 
same pin-parameters for a pin, then that pin-parameter gets set twice. This can happen 
programmatically also. 

[00217] If a parameter is set by a Slew statement such as 

VCC = Slew(0.01,2.0V); 

it means that VCC will reach its final value of 2.0 volts from its present value in a ramp 
with a Voltage Slew Rate of ± 0.01 volts per second. 

[00218] Specification set variables can also be passed into a Timings object in the 
TCG. The Timings object will then be initialized based on the selected variables. Such a 
mechanism could be used to customize a Timings object, as, for instance, by specifying 
leading and trailing edges of waveforms. 

C++ for TCGs 

[00219] With the above rules, the Test Condition Group can be declared in a C++ 
TestConditionGroup class, and initializing it as follows: 

[00220] A call is made to the TestConditionGroup member function 

Status setSpecificationSet(SpecificationSet *pSpecificationSet); 

which will set the specification set for the TestConditionGroup. This may either be a 
local specification set, or a named specification set, or null (if there is none). 

[00221] A call is made to the TestConditionGroup member function 

Status setLevels(Levels *pLevels); 

which will set the Levels object for the TestConditionGroup. This may either be a locally 
declared levels object, or an externally declared levels object, or null (if there is none). 

[00222] A call is made to the TestConditionGroup member function 

Status setTimings(Timings *pTimings); 
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which will set the Timings object for the TestConditionGroup. This will be either an 
externally declared Timings object, or null (if there is none). 
Bin Definitions 

[00223] The Bin Definitions class defines bins, a collection of counters that 
5 summarize the results of testing many DUTs. During the course of testing a DUT, the 
DUT can be set to any bin, e.g., to indicate the result of a particular test. As testing 
proceeds, the DUT may be set to another bin. The bin that the DUT is finally set to is the 
last such setting at the end of the test. The counter for this final bin is incremented at the 
end of the test of this DUT. A separate file with bin definitions should have the 
10 suffix .bdefs. 

[00224] Bin definitions are preferably hierarchical. For example, at an outermost 
level, there may be the PassFailBins with two bins named Pass and Fail. Then there could 
be several HardBins, some of which map to the Pass bin, and others which map to the Fail 
bin. The HardBins are said to be a refinement of the PassFailBins. Finally, there could be 
15 a large number of SoftBins, a refinement of HardBins, many of which map to the same 
Hard bin. Below is an example illustrating the hierarchy of bins: 

# 

# File CHIPbins.bdefs 

# 

20 

Version 1.2.3; 

BinDefs 

{ 

25 # The HardBins are an outermost level of 

# bins. They are not a refinement of any other 

# bins. 

BinGroup HardBins 
{ 

30 "3GHzPass": "DUTs passing 3GHz"; 

"2.8GHzPass": "DUTs passing 2.8GHz"; 
"3GHzFail": "DUTs failing 3GHz"; 
"2.8GHzFail": "DUTs failing 2.8GHz"; 
LeakageFail: "DUTs failing leakage"; 

35 } 



# The SoftBins are a next level of refinement. 

# SoftBins are a refinement of HardBins. 
BinGroup SoftBins : HardBins 
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{ 





"3GHzAllPass": 






"Good DUTs at 3GHz", 


"3GHzPass"; 




"3GHzCacheFail": 




5 


"Cache Fails at 3GHz", ' 


; '3GHzFail"; 




"3GHzSBFTFail": 






"SBFT Fails at 3GHz", 


"3GHzFail"; 




"3GHzLeakage": 






"Leakages at 3GHz", 


LeakageFail; 


10 


"2.8GHzAllPass": 






"Good DUTs at 2.8GHz 


","2.8GHzPass"; 




"2.8GHzCacheFail": 






"Cache Fails at 2.8GHz' : 


',"2.8GHzFail"; 




"2.8 GHzSBFTFail" : 




15 


"SBFT Fails at 2.8GHz" 


, "2.8GHzFail"; 




"2.8GHzLeakage": 






"Leakages at 2.8GHz", 


LeakageFail; 



} 

} 

20 [00225] In the above example, the most base bins are the BinGroup HardBins. A 
BinGroup X is said to be a group of base bins if some other BinGroup is a refinement of 
X. Thus, the BinGroup HardBins is a group of base bins since the BinGroup SoftBins is a 
refinement of HardBins. The bins of SoftBins are referred to as leaf bins. A BinGroup Y 
is said to be a group of leaf bins if no other BinGroup is a refinement of Y. 

25 [00226] The degenerate case of a BinDefs block with a single BinGroup Z in it will 
have Z to be a group of most base bins, as well as a group of leaf bins. BinGroup names 
are global in scope. There can be any number of BinDefs blocks, but the declared 
BinGroups must be distinct. A BinGroup from one BinDefs block is allowed to be a 
refinement of a BinGroup from another BinDefs block. So in the above example, 

30 SoftBins could be in a separate BinDefs block from HardBins. However, it is strongly 
recommended to have a single BinDefs block with all the BinGroups defined for the sake 
of readability. 

[00227] The above hierarchy can now be extended to count how many DUTs 
passed and failed, by adding another BinGroup. 

35 # 

# File CHrPbins.bdefs 

# . 

Version 1.2.3; 
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BinDefs 

{ 

# The PassFailBins are an outermost level of 
5 #bins. They are not a refinement of any other 

# bins. 

BinGroup PassFailBins 

{ 

Pass: "Count of passing DUTS."; 
10 Fail: "Count of failing DUTS."; 

} 

# The HardBins are a next level of refinement. 

# HardBins are a refinement of the PassFailBins, 
15 # as indicated by "HardBins : PassFailBins". 

BinGroup HardBins : PassFailBins 
{ 

"3GHzPass": "DUTs passing 3GHz", Pass; 
"2.8GHzPass": "DUTs passing 2.8GHz", Pass; 
20 "3GHzFail": "DUTs failing 3GHz", Fail; 

"2.8GHzFail": "DUTs failing 2.8GHz", Fail; 
LeakageFail: "DUTs failing leakage", Fail; 

} 

25 # The SoftBins are a next level of refinement. 

# SoftBins are a refinement of HardBins. 
BinGroup SoftBins : HardBins 

{ 

"3GHzAllPass": 

30 "Good DUTs at 3GHz", "3GHzPass"; 

"3GHzCacheFail": 

"Cache Fails at 3GHz", "3GHzFail"; 
"3GHzSBFTFail": 

"SBFT Fails at 3GHz", "3GHzFail"; 
35 "3GHzLeakage": 

"Leakages at 3GHz", LeakageFail; 
"2.8GHzAUPass": 

"Good DUTs at 2.8GHz","2.8GHzPass"; 
"2.8GHzCacheFail": 
40 "Cache Fails at 2.8GHz","2.8GHzFail"; 

"2.8GHzSBFTFail": 

"SBFT Fails at 2.8GHz", "2.8GHzFail"; 
"2.8GHzLeakage": 

"Leakages at 2.8GHz", LeakageFail; 

45 } 



[00228] This time, the most base bins are the BinGroup PassFailBins. They are 
typically not a refinement of any bins. The BinGroup HardBins are a refinement of the 
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PassFailBins and are also base bins. SoftBins are a refinement of the HardBins, and are a 
group of leaf bins. The above example had only three BinGroups in the hierarchy. Below 
is a more complicated hierarchy: 

BinDefs 

{ 

# A group of most base bins 
BinGroup A { ... } 

# A group of base bins that is a refinement of A 
BinGroup Ax : A { ... } 

# A group of leaf bins that is a refinement of Ax 
BinGroup Axx : Ax { ... } 

# A group of base bins that is a refinement of A 
BinGroup Ay : A { ...} 

# A group of leaf bins that is a refinement of Ay 
BinGroup Ayy : Ay { ... } 

# A group of most base bins 
BinGroup B { ... } 

# A group of leaf bins that is a refinement of B 
BinGroup Bx : B { ... } 

} 

[00229] In this example, Ax and Ay are refinements of A, Axx is a refinement of 
Ax and Ayy is a refinement of Ay. This example also provides BinGroups B and Bx 
where Bx is a refinement of B. The BinDefs declaration above with the BinGroups named 
PassFailBins, HardBins and SoftBins will be used as a continuing example in this section. 

[00230] Each bin in a BinGroup has: 

1 . a name which is either an identifier or a string literal 

2. a description which describes what this bin summarizes 

3. and if this bin is in a refinement BinGroup, the name of the bin it is 
a refinement of, also known as the base bin. 

[00231] The two bins in PassFailBins are named "Pass" and "Fail". The five bins 

in HardBins are named "3GHzPass", "2.8GHzPass", "3GHzFail", "2.8GHzFail", 

"LeakageFail". Bin names may be a literal string, or an identifier. Bin names must be 
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unique in a BinGroup, but may be duplicated across BinGroups. BinGroup names, 
however, are global in scope, and must be unique across a test plan. 

[00232] Of the five HardBins, the bins "3GHzPass" and "2.8GHzPass" both map to 
the "Pass" bin of the PassFailBins. The rest of the HardBins map to the "Fail" bins of the 
5 PassFailBins. 

[00233] Finally, there are eight SoftBins. The two failures at 3 GHz for SBFT (soft 
bin functional test) and Cache map to the "3GHzFail" HardBin. Likewise the two failures 
at 2.8GHz for SBFT and Cache map to the "2.8GHzFail" HardBin. Both the failures due 
to Leakage map to the same "LeakageFail" HardBin, regardless of the speed at which 
10 they occurred. For example, the coarsest test (at the outermost level) is whether a DUT 
passes or fails a test. A refinement is, for example, whether the DUT passes or fails a test 
at a particular frequency, e.g., 3 GHz, etc. 

[00234] Bins are assigned to DUTs in a Test Plan Flowltem, described below. A 

TestPlan Flowltem has a Result Clause in which the test plan describes the actions and 
1 5 transition to take place as the result of getting a particular result back from executing a 
test. It is at this point that a SetBin statement can occur: 

# A Flowltem Result clause. It is described later. 
Result 0 

{ 

20 # Action to be taken on getting a 0 back from 

# executing a test. 

# Set the bin to SoftBin."3GHZPass" expressing that the 

# DUT was excellent. 

25 SetBin SoftBins."3GHzPass"; 

} 

[00235] Many SetBin statements could execute during the course of running a test 
on a DUT. When the test is finally completed, the runtime will increment counters for the 
final bin that is set for that DUT, and for all its refinements. Consider a DUT which had 
30 the following SetBin statements executed during the course of its test: 

SetBin SoftBins."3GHzSBFTFail"; 
SetBin SoftBins."2.8GHzAllPass"; 

[00236] This DUT passed the 3 GHz Cache and Leakage tests, but failed the SBFT 

test, and so was assigned to the "3GHzSBFTFail" bin. It was then tested at 2.8GHz, and 
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all the tests passed. So the final bin assignment is to the "2.8GHzAllPass" bin, which is 
in the set of SoftBins. This final assignment will increment the counters of the following 
bins: 

1. SoftBins."2.8GHzAllPass" 

2. which is a refinement of HardBins."2. 8GhzPass" 

3 . which is a refinement of PassFailBins.'Tass" 

[00237] When the test completes, runtime will increment the counter of the final 

bin assignment of the DUT, and for all other bins it is a refinement of. 

[00238] A SetBin statement is allowed only on a leaf bin. It is illegal to set a base 
bin. The counter incrementing semantics above assures that: 

1. If the bin is a leaf bin, it is the number of times a SetBin statement 
was executed for this bin at the end of testing a DUT. 

2. If the bin is a base bin, it is the sum of the counters of the bins that 
it is a refinement of. 

[00239] Thus, in the above example, only SoftBins are allowed in a SetBin 
statement. The counter for HardBins."LeakageFail" is the sum of the counters for 
SoftBins."3GHzLeakageFail" and SoftBins."2.8GHzLeakageFail". Below are some rules 
regarding bin definitions: 

1 . A BinDefinitions declaration is comprised of several BinGroup 
declarations. 

2. Each BinGroup declaration has a name, an optional BinGroup 
name that it is a refinement of, followed by a block of bin 
declarations. 

3. Bin declarations comprise a name, followed by a description, 
optionally followed by the name of a base bin that this bin is a 
refinement of. 

4. Bin names can be a string literal, or an Id. The empty string should 
not be a valid bin name. Bin names should be unique among 
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names in the BinGroup declaration, but the same name could be 
used in other BinGroup declarations. 

5 . If a BinGroup declaration Xxx is a refinement of another BinGroup 
declaration Yyy, then all of the bin declarations in Xxx must 

5 declare the name of a base bin from Yyy. Thus, each of the bin 

declarations in SoftBins is a refinement of a bin of HardBins, since 
the SoftBins are declared to be a refinement of HardBins. 

6. A BinGroup declaration that is not a refinement of another 
BinGroup declaration, such as PassFailBins will preferably have 

10 Bin declarations that do not declare base bins. 

[00240] A bin Bbb has a set of bases which is the entire set of bins that Bbb is a 
refinement of. It is formally defined as follows: 

1 . If Aaa is the base bin of Bbb, then Aaa is in the set of bases of Bbb . 

2. Any base of Aaa is also in the set of bases of Bbb. 
1 5 [00241] BinGroup names are global in a TestPlan. 

[00242] Bin names are local to a BinGroup. 

[00243] A SetBin statement is only allowed for a leaf bin. 

C++ for Bin Definitions 

[00244] With above rules, an object type BinGroup can be constructed for each of 
20 the BinGroup declarations in the BinDefs declaration. The class BinGroup will have a 
subclass LeafBinGroup. The operations of these two classes are the same, except that 
BinGroup::incrementBin is a C++ protected operation, whereas 
LeafBinGroup: :incrementBin is a C++ public operation.' 

[00245] The following is a default constructor which builds a BinGroup or a 
25 LeafBinGroup which is not a refinement of any other BinGroup. 



[00246] Constructors: 
BinGroup(BinGroup& baseBinGroup); 
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LeafBinGroup(BinGroup& baseBinGroup); 
that builds a BinGroup that is a refinement of the given baseBinGroup. 

[00247] A method 

Status addBin(const String& binName, 

const String& description, 

const String& baseBinName); 
to define a bin and its description. If it is a most base bin, the baseBinName parameter 
must be the empty string. 

[00248] Methods to increment bin counters: 

Status incrementBin(const String& binName); 
This operation will increment the counter for this bin, and for all bins that are bases of this 
bin. The operation is protected in the class BinGroup, and is public in the class 
LeafBinGroup. 

[00249] Methods to reset bin counters 

Status resetBin(const String& binName); 
This operation will reset the counter for this bin, and for all bins that are the bases of this 
bin. 

[00250] Methods to get information about a bin: 
Status getBinDescription(const String& binName, 

String& description); 
Status getBaseBin(const String& binName, 
BinGroup* pBaseBinGroup, 
String& baseBinName); 
Status getBinValue(const String& binName, 
unsigned int& value); 

[00251] Iterators will be provided to get at all the currently defined bin names. 

[00252] TestPlan state will be include number of BinGroup members, one for each 
BinGroup declaration. The C++ for the above BinDefinitions would be as follows: 

// TestPlan constructor 
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5 



TestPlan::TestPlan() 

: m_PassFailBins(), // Default Constructor 
m_HardBins(&m_PassFailBins), 
m_SoftBins(&m_HardBins) 

{} 



// Bin initializations 



10 



m_PassFailBins.addBin("Pass", "Count of passing DUTS.",""); 
m_PassFailBins.addBin("Fail", "Count of failing DUTS.",""); 
m_HardBins.addBin("3GHzPass", "Duts passing 3GHz", "Pass"); 



[00253] 



State for a TestPlan includes a m_pCurrentBinGroup which is initialized to 



the undefined BinGroup (NULL) and the m_currenfBin undefined bin name (the empty 
15 string). Each time a SetBin statement is executed, the m_pCurrentBinGroup is changed to 
the indicated the named BinGroup and the m_currentBin to the named bin in the group by 
a call: 



causing this bin and all its base bins to have their counters incremented. 
[00255] The BinGroup counters are reset when the test plan is elaborated, but are 
not reinitialized each time a test is run. The counters can be reset by an explicit call to 
25 BinGroup:: resetBin. 

C. The Test Plan 

[00256] The test plan can be thought of as a main structure of the test program. 
The Test Plan can import files, as well as define similar constructs inline. Thus, it is 
possible to import a file given definitions of some globals, as well as declaring additional 
30 globals inline. 

CI. Test Plan Flows and Flowltems 

[00257] One of the critical elements of the Test Plan is the Flow. A Flow 
encapsulates a finite state machine. It comprises several Flowltems which run an 
IFlowable object and then transition to another flow item. Running an IFlowable involves 



20 [00254] 



// Translation of: SetBin SoftBins."3GHzAllPass"; 
pTestPlan->setBin("SoftBins","3GHzAUPass"); 

When the test plan completes execution, it will call 



m_pCurrentBinGroup->incrementBin(m_currentBin); 
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running an object that implements the IFlowable interface. Typical objects that 
implement the IFlowable interface are Tests and Flows themselves. 

[00258] Thus, a Flow has Flowltems which runs Tests and other Flows, and then 
transition to another Flowltem. It also provides for the opportunity to call user 
5 customized routines on various return results from running an IFlowable. Typically, a 
Flow thus has the following form: 

# 

# FlowTestl implements a finite state machine for the 

# Min, Typ and Max flavors of MyFunctionalTestl . On 
10 # success it tests TestlMin, TestlTyp, TestlMax 

# and then returns to its caller with 0 as a successful 

# status. On failure, it returns 1 as a failing status. 
# 

# Assume that the tests MyFunctionalTestl Min, ... all 
1 5 # return a Result of 0 (Pass), 1 and 2 (for a couple 

# of levels of failure). 

# Result 0 Result 1 Result 2 

# TestlMin TestlTyp return 1 return 1 

# TestlTyp TestlMax return 1 return 1 
20 # TestlMax return 0 return 1 return 1 

# 

Flow FlowTestl 
{ 

Flowltem FlowTestl_Min MyFunctionalTestl Min 
25 { 

Result 0 

{ 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 
30 GoTo FlowTestl_Typ; 

} 

Result 1 

{ 

35 Property PassFail = "Fail?; 

IncrementCounters FailCount; 
Return 1; 

} 

40 # This result block will be executed if 

# MyFunctionalTestlMin returns any of 

# 2, 5, 6, 7, -6, -5 or -4 
Result 2, 5:7, -6:-4 

{ 

45 Property PassFail = "Fail"; 
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IncrementCounters FailCount; 
Return 1; 

} 

} 

5 

Flowltem FlowTestl_Typ { ... } 
Flowltem FlowTestl_Max { ... } 

} 

[00259] The operation of the Flow FlowTestl is as follows: 
10 1. Starts up with executing Flowltem FlowTestl_Min. 

2. FlowTestl Min runs a functional test, MyFunctionalTestlMin. Details of 
this test are provided when the complete test plan is presented below. 

3. Nine results are expected from running this test, 0, 1,2, 5, 6, 7, -6, -5 or -4. 
The first two Result clauses handle 0 and 1 respectively, and the third 

1 5 handles all the rest of the result values. 

4. If result "0" (pass) occurs, then FlowTestl_Min will increment the counter 
PassCounter. It will then transition to a new Flowltem FlowTestl _Typ. 

5. If result "1" or result "2" occurs, then FlowTestl_Min will increment the 
counter FailCounter, and return from the flow. 

20 6. FlowTestl_Typ will operate in the same way, and on success call 

FlowTestlJVIax. 

7. FlowTestl_Max will operate in the same way, and on success return from 
FlowTestl with a successful result ("0"). 

[00260] Thus, FlowTestl will, on a successful run, run a device through the 
25 minimum, typical and maximum versions of Testl , and then return. FlowTest2 will 
operate in a like manner. 

[00261] A Flow as described above basically describes a Finite State Machine with 
states and transitions. The Flowltems are basically states, which will do the following: 

1 . Execute an IFlowable (it could be a previously defined Flow, or a Test, or 
30 a user defined Flow that can be implemented in C++ with the above rules). 
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2. Execution of the IFlowable return a numeric result. Based on the result, 

certain actions occur (updating some counters), and then one of two things 
happen: 

a. The Flow returns to the caller with a numeric result. 
5 b. The Flow continues by transitioning to another state (Flowltem). 

[00262] Thus, a Flowltem has the following components: 

A Flowltem has a name. 

A Flowltem has an IFlowable to be executed. 

A Flowltem has a number or Result clauses. 

1 0 Each Result clause of a Flowltem provides actions and ends with a transition and is 
associated with one or more result values. 

[00263] These items are syntactically as follows in a Flowltem. 

Flowltem <name> <IFlowable to be executed> 
{ 

1 5 Result <one or more result values> 

{ 

<actions for these result values> 
<transition for these result values> 

} 



20 



25 



Result <one or more other result values> 
{ 



} 



} 

[00264] The IFlowable to be executed could be either a Test, or a User-defined 
IFlowable, or a Flow. The actions for a result could be any of the following: 



30 



A Property Action to set string valued entities that are used by GUI tools to 
attribute results. This can be seen in the above FlowTestl example with: 
Property PassFail = "Pass"; 
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[00265] Properties are basically named string or integer valued entities that are 
associated with a Result clause. There can be any number of them, and they are 
preferably used by tools such as GUIs which a user would use to display information 
associated with this result. They have no effect on the actual result of the test, or the flow 
of the test. 

[00266] A Counters Action to increment some number of counters. This can be 
seen in the above example with: 

IncrementCounters PassCount; 
A Routine Call Action to call an arbitrary or user routine. This is discussed later. 

[00267] Finally, a Flowltem has a Transition which could either be a GoTo 
statement to transfer control to another Flowltem, or a Return statement to transfer control 
back to the caller (either a calling flow, or the system routine which initiated the test plan). 

Predefined Flows 

[00268] The typical use of Flow objects is to define a sequence of Tests. This 
sequence is then executed as a result of an event occurring in a Test Plan Server (TPS), i.e. 
the Execute Test Plan event. A test plan server on each site controller executes the user's 
test plan. However, Flow objects are also executed in response to other events. The name 
in parentheses is the name used in assigning Flows to these events. 

1 . System Load Flow (SysLoadFlow). This Flow is executed on the 
System Controller when a Test Plan is loaded onto one or more Site 
Controllers. It is executed prior to the actual loading of the Test 
Plan on any Site Controller. This flow allows the Test Plan 
developer to define actions that should originate from the System 
Controller. Such actions include broadcast load of Pattern files, 
Calibration actions, etc. 

2. Site Load Flow (SiteLoadFlow). This Flow is executed on the Site 
Controller after a Test Plan has been loaded onto the Site and 
initialized. This allows any Site-specific initialization to occur. 
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3. Lot Start/End Flows (LotStartFlow/LotEndFlow). These Flows 
execute on the Site Controllers when the Test Plan Server is 
notified of a start of a new lot. This is typically used in production 
environments to annotate datalog streams with lot-specific 
information. 

4. DUT Change Flow (DutChangeFlow). This Flow executes on the 
Site Controller when its DUT information changes. Again, this is 
typically used in production environments to update datalog 
streams. 

5. TestPlan Start/End Flows (TestPlanStartFlow/TestPlanEndFlow). 
These Flows execute on the Site Controller when the Test Plan 
Server is instructed to start executing the current Test Flow and 
when that flow finishes its execution. 

6. Test Start/End Flows (TestStartFlow/TestEndFlow). These Flows 
execute on the Site Controller when the Test Flow is starting to run 
a new Test and when that Test finishes its execution. 

7. Test Flow (TestFlow). This Flow is the main Flow object executed 
when the Test Plan Server receives an "Execute Test Plan" message. 

[00269] Note that if a user defines a Flow in the user' s Test Plan that is not the 
TestFlow or one of the other pre-defined flows, the preferred way to have it executed is 
to include it in the transition states of one of these pre-defined flows. 

A Test Plan Example 

[00270] In the example below, Flows are given along with comments that describe 
the finite state machine implemented by the flow. The finite state machine is given as a 
transition matrix. Rows of the matrix correspond to Flowltems, and columns to the result. 
The entries of a row of the matrix indicate the Flowltem that is transitioned to from the 
Flowltem of the row when the returned Result is the value specified in the column. 

[00271] A Test Plan with three flows, FlowTestl , FlowTest2 and FlowMain, is 
shown below. FlowTestl will operate as described above. It will run a test named 
MyFunctionalTestl in each of the "min", "typ" and "max" configurations. Likewise, 
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FlowTest2 will run MyFunctionalTest2 in each of these configurations. Finally, 
FlowMain will run FlowTestl and FlowTest2. The finite state machine transition matrix 
is provided in comments at the start of each of these flows. 

# 

# File mySimpleTestPlan.tpl 

# 

Version 0.1; 

Import xxx.pin; # Pins 

# Constants and variables giving limiting values. 
Import limits.usrv; 

# Import test condition groups 
Import myTestConditionGroups.tcg; 

# Import some bin definitions. 
Import bins.bdefs; 

# 

# Start of the test plan 

# . 

TestPIan Sample; 

# This block defines Pattern Lists file-qualified names and 

# Pattern List variables that are used in Test declarations. 

# Pattern list variables are deferred till customization is 

# examined. 
PListDefs 

{ 

# File qualified pattern list names 
pllA.plistpatlAlist, 
pl2A.plist:pat2AList 

} 

# The socket for the tests in this test plan (this is not imported, 

# but resolved at activation time): 
SocketDef = mytest.soc; 

# Declare some user variables inline 
UserVars 

{ 

# String name for current test 
String CurrentTest = "MyTest"; 

} 
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TestCondition TClMin 

TestConditionGroup = TCG1; 
Selector = min; 



TestCondition TClTyp 

TestConditionGroup = TCG1; 
Selector = typ; 



TestCondition TCI Max 

TestConditionGroup = TCG1 ; 
Selector = max; 



# Likewise for TC2Min, TC2Typ, TC2Max ... 



# 

# Declare a FunctionalTest. "FunctionalTest" refers to a C++ 

# test class that runs the test, and returns a 0, 1 or 2 as 

# a Result. The Test Condition Group TCG1 is selected with 

# the "min" selector by referring to the TClMin TestCondition, 
# 

Test FunctionalTest MyFunctionalTestlMin 

{ 

PListParam = patlAList; 
TestConditionParam = TClMin; 

} 

# Another FunctionalTest selecting TCG1 with "typ" 
Test FunctionalTest MyFunctionalTestlTyp 

{ 

PListParam = patlAList; 
TestConditionParam = TClTyp; 

} 

# Another FunctionalTest selecting TCG1 with "max" 
Test FunctionalTest MyFunctionalTestlMax 

{ 

PListParam = patlAList; 
TestConditionParam = TCI Max; 

} 

# Now select TCG2 with "min" 
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Test FunctionalTest MyFunctionalTest2Min 

{ 

PListParam = pat2AList; 
TestConditionParam = TC2Min; 

5 } 

# Likewise for TCG2 with "typ" and TCG2 with "max" 
Test FunctionalTest MyFunctionalTest2Typ 

{ 

1 0 PListParam = pat 1 AList; 

TestConditionParam = TC2Typ; 

} 

Test FunctionalTest MyFunctionalTest2Max 
15 { 

PListParam = pat 1 AList; 
TestConditionParam = TC2Max; 

} 

20 # 

# At this time the following Test objects have been defined 

# MyFunctionalTestlMin 

# MyFunctionalTestlTyp 

# MyFunctionalTestlMax 
25 # MyFunctionalTest2Min 

# MyFunctionalTest2Typ 

# MyFunctionalTest2Max 
# 

# 

30 # Counters are variables that are incremented during the 

# execution of a test. They are Unsignedlntegers that are 

# initialized to zero. 
# 

Counters {PassCount, FailCount} 

35 

# 

# Flows can now be presented. A Flow is an object that 

# essentially represents a finite state machine which 

# can execute "Flowables", and transition to other flowables based 
40 # on the Result returned from executing a Flowable. A Flow can also 

# call another flow. 
# 

# A Flow consists of a number of Flowltems and transitions 

# between them. Flowltems have names which are unique in 
45 # the enclosing Flow, execute a "Flowable" object, and then 

# transition to another Flowltem in the same enclosing Flow. 
# 

# Flowable objects include Tests and other Flows. When 

# a Flowable object executes, it returns a numeric Result 
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# which is used by the Flowltem to transition to another 

# Flowltem. As a result of this, both Tests and Flows 

# terminate by returning a numeric Result value. 

# 

# FlowTestl implements a finite state machine for the 

# Min, Typ and Max flavors of MyFunctionalTestl . On 

# success it tests TestlMin, TestlTyp, TestlMax 

# and then returns to its caller with 0 as a successful 

# Result. On failure, it returns 1 as a failing Result. 

# Assume that the tests MyFunctionalTestlMin, ... all 

# return a Result of 0 (Pass), 1 and 2 (for a couple 

# of levels of failure). The Transition Matrix of the 

# finite state machine implemented by FlowTestl is: 
# 

# Result 0 Result 1 Result 2 
§ 

# FlowTestl_Min FlowTestl _Typ return I return 1 

# FlowTestl_Typ FlowTestlJVfax return 1 return 1 

# FlowTestl_Max return 0 return 1 return 1 
# 

# where the IFlowables run by each Flowltem are: 

# Flowltem IFlowable that is run 

# FlowTestl_Min MyFunctionalTestlMin 

# FlowTestl_Typ MyFunctionalTestl Typ 

# FlowTestl_Max MyFunctionalTestl Max 
# 

Flow FlowTestl 
{ 

Flowltem FlowTestl _Min MyFunctionalTestlMin 
{ 

Result 0 

{ 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 
GoTo FlowTestlTyp; 

} 

Result 1,2 

{ 

Property PassFail = "Fail"; 
IncrementCounters FailCount; 
Return 1; 

} 

} 

Flowltem FlowTestl_Typ MyFunctionalTestlTyp 
{ 

Result 0 

{ 
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Property PassFail = "Pass"; 
IncrementCounters PassCount; 
GoTo FlowTestl_Max; 

} 

5 

Result 1,2 

{ 

Property PassFail = "Fail"; 
IncrementCounters FailCount; 
10 Return 1: 

} 

} 

# Likewise for FlowTestl_Max 
1 5 Flowltem FlowTestl_Max MyFunctionalTest 1 Max 

{ 

Result 0 

{ 

Property PassFail = "Pass"; 
20 IncrementCounters PassCount; 

Return 0; 

} 

Result 1,2 

25 { 

Property PassFail = "Fail"; 
IncrementCounters FailCount; 
Return 1; 

} 

30 } 

} 



# 

35 # FlowTest2 is similar to FlowTestl . It implements a 

# finite state machine for the Min, Typ and Max flavors 

# of MyFunctionalTest2. On success it tests Test2Min, 

# Test2Typ, Test2Max and then returns to its caller with 

# 0 as a successful Result. On failure, it returns 1 as 
40 # a failing Result. 

# 

# Assume that the tests MyFunctionalTest2Min, ... all 

# return a Result of 0 (Pass), 1 and 2 (for a couple 

# of levels of failure). The Transition Matrix of the 
45 # finite state machine implemented by FlowTest2 is: 

# 

# Result 0 Result 1 Result 2 
# 

# FlowTest2_Min FlowTest2_Typ return 1 return 1 



WO 2005/114235 



PCT7JP2005/009813 



88 

# FlowTest2_Typ FlowTest2_Max return 1 return 1 

# FlowTest2_Max return 0 return 1 return 1 

# 

# Where the IFlowables run by each Flowltem are: 

# Flowltem IFlowable that is run 

# FlowTest2_Min MyFunctionalTest2Min 

# FlowTest2__Typ MyFunctionalTest2Typ 

# FlowTest2_Max MyFunctionalTest2Max 



# 

10 Flow FlowTest2 

{ 

#... 



15 

# 

# Now the FlowMain, the main test flow, can be presented. It 

# implements a finite state machine that calls FlowTestl 

# and FlowTest2 as below: 

20 # 

# Result 0 Result 1 
# 

# FlowMain_l FlowMain_2 return 1 

# FlowMain_2 return 0 return 1 
25 # 

# Where the IFlowables run by each Flowltem are: 

# Flowltem IFlowable that is run 

# FlowMain_l FlowTestl 

# FlowMain_2 FlowTest2 
30 Flow FlowMain 

{ 

# The first declared flow is the initial flow to be 

# executed. It goes to FlowMain_2 on success, and 

# returns 1 on failure. 

35 Flowltem FlowMainJ FlowTestl 

{ 

Result 0 

{ 

Property PassFail = "Pass"; 
40 IncrementCounters PassCount; 

GoTo FlowMain_2; 

} 

Result 1 

45 { 

# Sorry ... FlowTestl failed 
Property PassFail = "Fail"; 
IncrementCounters FailCount; 
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# Add to the right soft bin 
SetBin SoftBins."3GHzSBFTFail"; 

Return 1; 

} 

} 

Flowltem FlowMain_2 FlowTest2 
{ 

Result 0 

{ 

# All passed! 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 

# Add to the right soft bin 
SetBin SoftBins."3GHzAllPass"; 



Return 0; 



} 



Result 1 

{ 

# FlowTestl passed, but FlowTest2 failed 
Property PassFail = "Fail"; 
IncrementCounters FailCount; 

# Add to the right soft bin 
SetBin SoftBins."3GHzCacheFail"; 

Return 1; 



} 



} 



TestFlow = FlowMain; 
[00272] The above test plan is structured as follows in a preferred order: 

1 . First, a version number is provided. This number is used to ensure 
compatibility with the compiler version. 

2. Then, a number of imports are declared. These are various files with 
declarations needed in order to resolve names used in the test plan. 

3 . Next, the Test Plan name is declared, after which come the inline 
declarations of the test plan. 
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4. Next a set of PListDefs are declared. These include file-qualified names 
naming GlobalPLists from the named files. They also include Pattern List 
variables. Pattern List variables are variables that can be initialized in 
custom flowables at execution time. They provide a means of delaying 
binding tests to actual pattern lists until runtime. 

5. Next, a set of UserVars is declared. These include a string. 

6. Some Counters are then declared, to determine the number of tests passed 
and failed. Counters are simply variables that are initialized to zero, and 
incremented at IncrementCounter statements. They are different from Bins 
described earlier which have the semantics that only the currently set bin is 
incremented at the end of the test of a DUT. 

7. Next, a series of Test Conditions is declared. Each of these specifies a Test 
Condition Group and a selector. In this example, the Test Condition 
Groups come from mytestconditionsgroups.tcg. However, they could have 
been inline in the test plan. 

8. Next, a series of Flow ables or Tests is declared. Each of this is known 
Test FunctionalTest which selects a Pattern List and a test condition. Thus 
for instance, MyFunctionalTestlMax selects the test condition TClMax 
and a pattern list. 

9. Following this, three flows are declared, FlowTestl, FlowTest2 and 
FlowMain. Flows run Flowables. Flowables include Tests (such as 
MyFunctionalTestlMax) and other flows (such as FlowTestl and 
FlowTest2). Each of FlowTestl and FlowTest2 run through the minimum, 
typical and maximum versions of Testl and Test2 respectively. The flow 
FlowMain calls the earlier declared flows, FlowTestl and then FlowTest2. 

10. Finally, the TestFlow event is assigned to the FlowMain Flow. Thus the 
flow FlowMain is the one that will be executed by this test plan when a 
user chooses to Execute this plan. 

C++ for Flows 
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[00273] With the above rules, a C++ implementation can be done for most of the 

elements, with the exception of the Flows themselves. 

C++ for Flowltems 

[00274] The C++ class to represent a Flowltem may have the following interface: 

5 An operation 

Status setFlowable(IFlowable* pIFlowable); 

which will set the IFlowable that will be executed for this Flowltem. 

[00275] Once the Flowltem returns from the set of calls needed to execute this 
IFlowable, it will need to increment a list of counters depending on the Result value. To 
10 this end, the Flowltem needs to have a vector of counters that is to be incremented. This 
is initialized by a call: 

Status setCounterRefs(unsigned hit result, 

CounterRefList counterRefs); 

Calling this sets up a vector of references to counters into the Flowltem, so that it can 
15 increment them once the IFlowable completes execution. For example, the statement 

IncrementCounters A, B, C; 

would preferably use the above call as follows: 

// Somewhere earlier 
CounterRefList counters; 

20 

// Code for Result clause 
// Result 2, 3 {...} 
//offlowObject 
counters.resetQ; 
25 counters.add(&A); 

counters.add(&B); 
counters.add(&C); 

flowObj ect.setCounterRefs(2, counters); 
flowObject.setCounterRefs(3, counters); 

30 [00276] A temporary CounterRefList object named counters is used. Initially 

counters.resetQ is called, followed by a number of counters. add() calls to set up the 

counters list. This is then used to setup the vector of counter addresses to be updated for 

result values 2 and 3. 
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[00277] The Flowltem may then need to transition to another Flowltem on a 
particular result: 

Status setTransition(unsigned int result, Flowltem* pFlowItem); 

Several such calls will naturally need to be made in the case that a certain Result clause 
deals with many result values. 

[00278] The Flowltem may need to return a result. This is done by: 

Status setRetuniResult(unsigned int result, 

unsigned int returnResult); 

[00279] For example, for the Flowltem FirstFlowItem in the previous example, the 
above would be called with the value "2" for "result" and "1" for "returnResult". 

Finally, the Flowltem needs an operation to execute: 

Status execute(unsigned int& result, Flowltem* pNextFlowItem); 
[00280] This operation will execute the IFlowable, then update the indicated 
counters, and then either return a Result, or a pointer to the next Flowltem. If this pointer 
is NULL, then the result is the returned value. 

[00281] The code that would be generated for Flowltem FlowMainJ is as follows: 



Flowltem FlowMain_l ; 
Flowltem FlowMain_2; 

CounterRefList counters; 

FlowMain_l.setFlowable(FlowTestl); 

// Result 0 

counters.reset(); 

counters.add(&PassCount); 

FlowMain_l .setCounterRefs(0, counters); 

FlowMain_l .setTransition(0, &FlowMain_2); 

// Result 1 

counters.resetQ; 

counters.add(&FailCount); 

FlowMain_l .setCounterRefs(l, counters); 

// The following call from ITestPlan will set the 
// current bin group and bin name. 
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pTestPlan->setBin("SoftBins", "3 GHzSBFTFail"); 
FlowMain_l.setReturnResult(l, 1); 

[00282] The code generated above sets up FlowMain_l to run the IFlowable 

"FlowTestl", and then sets it up to increment the appropriate list of counters for each 

5 result, and finally to take the necessary actions. The necessary action in the case of result 

"0" is a transition to FlowMain_l, and in the case of result "1" is a return. 

C2. Counter Support in a TestPIan 

[00283] Counters are variables that are initialized to zero, and can be incremented 

by an IncrementCounter statement at various points during a test run. They are different 
1 0 from Bins, which are incremented only at the end of the test. Furthermore, bins are 

hierarchical while counters are simple variables. Thus, counters are a much simpler and 
more limited facility than bins. 

[00284] Counters can be supported in a TestPIan via a member of a Counters class 
that maintains a set of named counters which are unsigned integers. Objects will be 
1 5 defined in this class via a Counters declaration. Counters will not be automatically reset 
when a test starts, thus allowing a TestPIan to gather counts over testing many DUTs. 
Methods will be provided to reset, increment and query the value of a counter. This 
enables an alternative to binning in order to determine counts as a result of running a test. 

[00285] The TestPIan preferably contains a member variable, m modifiedCounters, 
20 which is the set of counters modified by running the test on a DUT. This set is initialized 
to the empty set at the start of the test. At each place an IncrementCounters call is made, 
code will be generated to add the named counters to the mjnodifiedCounters member. 
Thus, this member gathers together all the counters that were modified during the 
execution of a test on a DUT. 

25 C++ for the Flow Object 

[00286] Once all the Flowltems have been created, the Flow object can be created 
as a C++ object as shown below: 



An operation to add a Flowltem 
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Status addFlowItem(FlowItem* pFlowItem, bool isInitalFlowItem); 

which will add the indicated Flowltem to the Flow. The boolean is set to 
True if this is the initial Flowltem of the Flow. 

An operation to execute the Flow 
5 Status executeFlow(unsigned int& result); 

[00287] This will preferably return when the Flow returns, with the result of 
executing the flow. The action of this is to start executing the flow with the initial 
Flowltem. It will keep executing Flowltems as long as the current Flowltem returns a 
next Flowltem to execute. When the current Flowltem returns a Result, then this 
1 0 operation completes with that Result. 

[00288] Hence, the C++ code generated for a Flow has several repeated calls to 
addFlowItem() in order to add Flowltems to the Flow. The executeFlow() operation will 
occur when this Flow in the Test Plan is selected for execution. 

C3. Test Classes 

1 5 [00289] In general majority of the program code is data for device test, and the rest 
is the code of test program, which realizes the test methodology. This data is DUT- 
dependent (e.g., power supply conditions, signal voltage conditions, timing conditions, 
etc.). The test code consists of methods to load the specified device conditions on to ATE 
hardware, and also those needed to realize the user specified objectives (such datalogging, 

20 etc). 

[00290] As explained above, to increase the reusability of test code, such code 
should be independent of any device-specific data (e.g., pin name, stimulus data, etc.), or 
device-test-specific data (e.g., conditions for DC units, measurement pins, number of 
target pins, name of pattern file, addresses of pattern programs, etc.). If code for a test is 
25 compiled with data of these types, the reusability of the test code would decrease. 

Therefore, any device-specific data or device-test-specific data should be made available 
to the test code externally, as inputs during code execution time. 

[00291] In the open architecture test system, a Test Class, which is an 
implementation of the ITest interface, realizes the separation of test data and code (and 
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hence, the reusability of code) for a particular type of test. Such a test class could be 
regarded as a "template" for separate instances of it, which differ from each other only on 
the basis of device-specific and/or device-test-specific data. Test classes are specified in 
the test plan file. Each Test class typically implements a specific type of device test or 
5 setup for device test. For example, Functional, AC and DC Parametric tests are 

preferably implemented by separate Test classes. However, custom test classes can also 
be used in test plans. 

[00292] Test classes allow the user to configure class behavior by providing 
parameters that are used to specify the options for a particular instance of that test. For 

1 0 example, a Functional Test will take parameters PList and TestConditions, to specify the 
Pattern List to execute, and the Level and Timing conditions for the test, respectively. 
Specifying different values for these parameters (through the use of different "Tesf 
blocks in the test plan description file) allows the user to create different instances of a 
Functional Test. Figure 5 shows how different test instances 502 would be derived from a 

1 5 single test class 504. 

[00293] These classes should be designed to allow the compiler 400 to take the 
description of the tests and their parameters from the test plan file and generate correct 
C++ code, which can be compiled and linked to generate the test program. Test class 
instances may be added to objects describing test flow to create a complex execution 
20 sequence of device tests. 

C4. Derivation from ITest and IFlowable 

[00294] As mentioned above, Test classes derive from ITest. With the above rules, 
these can be implemented in C++ classes that implement the ITest interface. In addition 
to the methods specified for the ITest interface, these classes provide the Test-specific 
25 intelligence and logic required to perform specific classes of device test. Test classes also 
implement the IFlowable interface. As a consequence of this, instances of Test classes 
can be used in Flowltems to run tests. 

Customization 

[00295] Customization mechanisms are provided to allow users to call C functions, 
30 and develop their own classes implementing the ITest and IFlowable interfaces. 
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Pre-Header 

[00296] A TPL provides a generic mechanism for defining a test class in the test 

5 system. Test engineers can use this mechanism to create custom test classes that can be 
loaded and used by the test system without additional facilities. Test engineers can also 
develop their own test classes implementing the ITest and IFlowable interfaces described 
above. A pre-header supports the feature of custom test classes by providing 
introspection capabilities to the C++ language. 

1 0 [00297] If an object of a test class can be interrogated regarding its methods and 
signatures, then it can be verified that the appropriate parameters are available for 
inclusion in the generated source code. Such a feature is useful for error checking and 
validation during the translation phase. If the test engineer made a mistake in the names 
of parameters, or the number (or possibly the types) of arguments to these parameters, this 

1 5 mistake can be caught during the translation phase and a meaningful error message can be 
produced at translation time instead of waiting for a compile-time error message from the 
C++ compiler. 

[00298] Introspection refers to the ability to ask an object to look within itself and 
return information regarding its attributes and methods. Some languages, such as Java, 
20 provide this ability as a part of the language. Other languages, such as Visual Basic, 
impose such a requirement on objects intended to be used with it. C++ makes no 
provisions for this feature. 

[00299] In one embodiment, the introspection capability of the pre-header is also 
useful for providing default parameter values as well as 'indications of optional parameters. 
25 In addition, if this capability is provided as a part of the implementation of test classes, 
then graphical user interface (GUI) applications can also use this information to 
dynamically build up dialogs and other user interface elements to help test engineers to 
make effective use of these classes. In another embodiment, the test class developer can 
specify, in a single text-based source file (per test class), the public methods/attributes of 
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the test class that the developer has designated as the ones required to parameterize the 
test class. 

[00300] Note that a single source is preferred. In other words, one does not want to 
have the description of the parameterization interface of a test class in one file and the 
5 C++ interface description in another independent (header) file, and be burdened with the 
need to keep both sources synchronized. Towards this end, a "text-based" description of 
the test class is embedded in a pre-header file, which is used by the compiler for the 
purpose of introspection, as well for generating the C++ header for the test class. The 
generated C++ header file is the one used to finally compile the test class C++ code. 

10 [00301] The use of headers in C++ is well known. However, since the C++ 

language is difficult to parse and interpret, an embodiment of the invention defines a pre- 
header file that is compiled by the TPL compiler to create a C++ header file, which is then 
used by the C++ compiler to create the test program. According to this embodiment, the 
test class developer writes a pre-header file, which allows visibility into the corresponding 

1 5 test classes or other test entities. 

[00302] The following example illustrates the concept of the pre-header file for a 
test class in accordance with an embodiment of the present invention. Consider the 
following excerpt from a source file, with a test FuncTestl : 

20 TestCondition TCI 

{ 

TestConditionGroup = TCG1 ; # Previously defined TCG for 
Levels 

Selector = min; 

25 } 

TestCondition TC2 

{ 

TestConditionGroup = TCG2; # Previously defined TCG for 
30 Timing 

Selector = min; 

} 

Test FunctionalTest FuncTestl 
35 { 

PListParam = patListl ; # Previously defined pattern list 

TestConditionParam = TCI; 
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TestConditionParam = TC2; 

} 

[00303] The C++ compiler needs to know what a FunctionalTest entails in order to 
determine whether the declaration of FuncTestl is legal. Rather than build the knowledge 
of a FunctionalTest into the C++ compiler, the definition of what a FunctionalTest entails 
can be specified in the pre-header. 

[00304] Assume that FunctionalTest is a C++ class having base classes Testl and 
Test2, and having members which are a parameter list (PList) and an array of test 
conditions (TestConditions). The C++ compiler needs to know about the types of the 
members of FunctionalTest in order to recognize that the above declaration of FuncTestl 
is legal. 

[00305] Furthermore, in order to generate a C++ object declaration for FuncTestl , 
a C++ header for the class FunctionalTest needs to be constructed. This requires the C++ 
compiler to also know the base classes of the FunctionalTest class, the names of its 
members, and other such information. 

[00306] The pre-header of an embodiment of the invention provides the C++ 
compiler with the information it needs to both recognize the legality of declarations, and 
to generate C++ headers and object declarations that correspond to the declarations. 

[00307] Note that a FunctionalTest may be a simple type (as far as parameterization 
is concerned), and thus uses a simple description for parameterization. A test class 
developer writes a pre-header, FunctionalTest.ph, that supports the above 
parameterization as follows (assume that pre-headers are available for the base test classes 
Testl and Test2): 

1 Version 1.0; 

2 # 

3 # Parameterization specification pre-header for FunctionalTest 

4 # 

5 Import Testl .ph; # For base class Testl 
' 6 Import Test2.ph; # For base class Test2 

7 TestClass = FunctionalTest; # The name of this test class 

8 PublicBases = Testl, Test2; # List of public base classes 

9 # The parameters list or "parameter block": 

10 Parameters 

11 { 
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12 # The following declaration specifies that a FunctionalTest has 

13 # - a parameter of type PList 

14 # - [represented by C++ type Tester: :PatternTree] 

15 # - stored in a member named m_pPatList 

5 16 # - a function to set it named setPatternTree. 

17 # - a parameter description for the GUI to use as a tool tip 

18 PList PListParam 

19 { 

20 Cardinality = 1; 

10 21 Attribute = m_pPatList; 

22 SetFunction = setPatternTree; 

23 Description = "The PList parameter for a FunctionalTest"; 

24 } 

25 # 

15 26 # The following declaration specifies that a FunctionalTest has 

27 # - 1 or more parameters of type TestCondition 

28 # - [represented by C++ type Tester: :TestCondition] 

29 # - stored in a member named m_testCondnsArray 

30 # - a function to set it named addTestCondition. 

20 31 # - a parameter description for the GUI to use as a tool tip 

32 # The [implement] clause causes the translation phase of to 

33 # generate a default implementation of this function. 

34 # 

35 TestCondition TestConditionParam 

25 36 { 

37 Cardinality = 1-n; 

38 Attribute = m_testCondnsArray; 

39 SetFunction = addTestCondition [Implement]; 

40 Description = "The TestCondition parameter for a 
30 FunctionalTest"; 

41 } 

42 } 

43 # 

44 # The section below is part of the Pre-Header which is an escape 
35 45 # into C++ code. This will be referred to as a "template block." 

46 # 

47 # Everything in this section will be reproduced verbatim in the 

48 # generated header file, except for "$Class", "$Inc'\ 

49 # "$ParamAryTypes'\ "$ParamAttrs'i, "$ParamFns" and 
40 "$ParamImpls". 

50 # 

51 # Note that no comments beginning with the '#' character are 
supported 

52 # within the following section. 

45 53 # 

54 CPlusPlusBegin 

55 Sine 
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56 


namespace 




57 


{ 




58 


class SClass 




59 


{ 


5 


60 


// Array types for parameters storage: 






a>jr <tr<tiii.f\ry l ypes 




62 


pUDllC. 




63 


virtual void preExecO; 




64 


virtual void execfV 


10 


65 


virtual void postExecO; 




66 


j>r araiiif ns 




67 






68 


private: 




69 


double m someVar; 


15 


70 


SParamAttrs 




71 
72 


}; "' 




73 






74 


SParamlmpIs 


20 


75 


} // End namespace 




76 


CPlusPlusEnd 



C++ For Parameterized Test Classes 

[00308] As the compiler processes a pre-header file, it builds up the values of the 
25 compiler variables such as Sine, SClass, SParamAry Types, and others. This enables it 
to then create a C++ header by generating the C++ code verbatim, and expanding in the 
values of the compiler variables Sine, SClass, etc. at the indicated places. For 
FunctionalTest.ph, it creates the following C++ header file FunctionalTest.h for the 
FunctionalTest class. 



30 1 #line 7 "./FunctionalTestph" 

2 #include <ITest.h> 

3 #line 5 "./FunctionalTestph" 

4 #include <Testl.h> 

5 #line 6 "./FunctionalTestph" 
35 6 #include <Test2.h> 

7 #line 55 "./FimctionalTestph" 

8 #include <vector> 

9 #line 55 "./FunctionalTestph" 

10 #include <Levels.h> 

40 11 #line 55 "./FunctionalTestph" 
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12 #include <TestCondnGrp.h> 

13 ... 

14 #line 56 "./FunctionalTest.ph" 

15 namespace 
5 16 { 

17 #line 7 "./FunctionalTest.ph" 

18 class FunctionalTest : public ITest, 

19 #line 8 "./FunctionalTestph" 

20 public Testl , 
10 21 #line 8 "./FunctionalTestph" 

22 public Test2 

23 #line 59 "./FunctionalTestph" 

24 { 

25 // Array types for parameters storage: 
15 26 #line 61 "./FunctionalTest.ph" 

27 public: 

28 #line 37 "./FunctionalTestph" 

29 typedef std::vector<Tester::TestCondition *> 
TestConditionPtrsAry_t; 

20 30 #line 62 "./FunctionalTestph" 

31 public: 

32 virtual void preExecO; 

33 virtual void exec(); 

34 virtual void postExec(); 

25 35 public: 

36 Mine 7 "./FunctionalTest.ph" 

37 void setName(OFCString &name); # Automatic for all tests 

38 #line 22 "./FunctionalTest.ph" 

39 void setPatternTree(PatternTree *); 
30 40 #line 23 "./FunctionalTest.ph" 

41 String getPListParamDescription() const; 

42 #line 39 "./FunctionalTestph" 

43 void addTestCondition(TestCondition *); 

44 #line 40 "./FunctionalTestph" 

35 45 void getTestConditionParamDescriptionO const; 

46 #line 67 "./FunctionalTestph" 

47 

48 private: 

49 double m_someVar; 

40 so #line 70 "./FunctionalTest.ph" 

51 private: 

■ 52 #line 7 "./FunctionalTestph" 

53 OFCString m_name; # Automatic for all tests 

54 #line 21 "./FunctionalTestph" 

45 55 Tester: :PatternTree *m_pPatList; 

56 #line 38 "./FunctionalTestph" 

57 TestConditionPtrsAry_t m_testCondnsArray; 
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58 #line 71 "./FunctionalTestph" 

59 

60 }; 

61 ... 

5 62 #line 7 "./FunctionalTestph" 

63 inline void 

64 #line 7 "./FunctionalTestph" 

65 FunctionalTest::setName(OFCString &name) 

66 #line 74 "./FunctionalTesth" 
10 67 { 

68 m name = name; 

69 return; 

70 } 

71 #line 39 "./FunctionalTestph" 
15 72 inline void 

73 #line 39 "./FunctionalTestph" 

74 FunctionalTest::addTestCondition(TestCondition *arg) 

75 #line 74 "./FunctionalTestph" 

76 { 

20 77 mtestCondnsArray.pushback(arg); 

78 return; 

79 } 

so #line 23 "./FunctionalTestph" 

81 inline void 

25 82 Tester::StringFunctionalTest::getPListParamDescription() 

83 { 

84 return "The PList parameter for a FunctionalTest"; 

85 } 

86 #line 40 "./FunctionalTestph" 
30 87 inline void 

88 Tester: '.String 
FunctionalTest::getTestConditionParamDescriptionO 

89 { 

90 return "The TestCondition parameter for a FunctionalTest"; 

35 91 } 

92 #line 75 "./FunctionalTestph" 

93 } // End namespace 

[00309] As indicated above, the pre-header file enables the compiler to check the 
40 validity of declarations for the FunctionalTest test class, to generate source code for it, 
and to generate a C++ header file for the test class. 



[00310] As an example, consider the FunctionalTest declaration given earlier, 
reproduced below for convenience: 
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Test FunctionalTest FuncTestl 
{ 

PListParam = patListl ; # Previously defined pattern list 

TestConditionParam = TCI; 
5 TestConditionParam = TC2; 

} 

[00311] The compiler generates the following source code for the above 
FunctionalTest construct according to the declaration of the C++ header file: 

FunctionalTest FuncTestl; 
10 FuncTestl. setName("FuncTestl"); 

FuncTest 1 . setPatternTree(&patList 1 ); 
FuncTest 1 . addTestCondition(&TC 1 ) ; 
FuncTest 1 . addTestCondition(&TC2) ; 

[00312] Note that the name is also generated for the description function. Each 

1 5 parameter named Xxx is associated with a member function: 

Status getXxxDescription() const; 

that returns the string with a description for the tool tip that the GUI can use. 

Other Pre-Header Features 

[00313] The pre-header supports other user-defined enumerations as an additional 
20 type. This allows the GUI to provide a drop-down list of possible choices that can be 

used for setting the value of a particular parameter. Furthermore, the pre-header provides 
a feature to associate a number of parameters that can be thought of as a table. For 
example, it may be convenient to implement an array of "properties" as an associated set 
of an array of strings for the names and an array of integers for the values. In one 
25 embodiment, this feature is implemented by the use of an array of custom types. This 
feature is illustrated in the following example: 1 

# 

# File FooBarTest.ph 
# 

30 # Parameterization specification pre-header for 

# custom test class FoobarTest 

# 



35 Version 1.0; 



Import Testl.ph; 
TestCIass = FoobarTest; 



# For base class Testl 
# The name of this test class 
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PublicBases = Testl; # List of public base classes 

# The parameters list: 
Parameters 

5 { 

# An enumerated type 

Enum FBEnum = FBI, FB2, FB3; 

# Define an FBEnum parameter. 
10 FBEnum FBE 

{ 

Cardinality = 1; 
Attribute = m_fb; 
SetFunction = setFb; 

1 5 Description = "The FBE parameter for a Foobar Test"; 

} 

# This class has an array of name-number pairs that is 

# interpreted in the class. 
20 ParamGroup 

{ 

Cardinality = On; 

# The Name field in this array is: 
25 # - of type String 

# - [represented by C++ type Tester ".String] 

# - stored in a member named m_NameArray 

# - a function to set it named addName. 

# - a parameter description for the GUI to use as a tool tip 
30 String Name 

{ 

Attribute = mJSfameArray; 
SetFunction = addName; 
Description = "A Name with a Value"; 

35 } 

# The Number field in this array is: 

# - of type Integer 

# - [represented by C++ type int] 

40 # - stored in a member named mJSfumberArray 

# - a function to set it named addNumber. 

# - a parameter description for the GUI to use as a tool tip 
Integer Number 

{ 

45 Attribute = m_NumberArray; 

SetFunction = addNumber; 
Description = "The value of the Name"; 

} 
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# The following declaration specifies that a FunctionalTest has 

# - a parameter of type PList 

# - [represented by C++ type Tester: :PatternTree] 
5 # - stored in a member named m_pPatList 

# - a function to set it named setPatternTree. 

# - a parameter description for the GUI to use as a tool tip 
PList PListParam 

{ 

10 Cardinality = 1; 

Attribute = mjpPafList; 
SetFunction = setPatternTree; 

Description = "The PList parameter for a FunctionalTest"; 

} 

15 

# 

# The following declaration specifies that a FunctionalTest has 

# - 1 or more parameters of type TestCondition 

# - [represented by C++ type Tester: : TestCondition] 
20 # - stored in a member named m_testCondnsArray 

# - a function to set it named addTestCondition. 

# The [implement] clause causes the translation phase of to 

# generate a default implementation of this function. 
# 

25 TestCondition TestConditionParam 

{ 

Cardinality = 1-n; 
Attribute = m_testCondns Array; 
SetFunction = addTestCondition [Implement]; 
30 Description = "The TestCondition parameter for a 

FunctionalTest"; 
} 

} 

35 CPlusPlusBegin 
Sine 

namespace 

{ 

class SClass 
40 { 

// Array types for parameters storage: 
SParamAry Types 

public: 

virtual void preExecO; 
45 virtual void exec(); 

virtual void postExecQ; 
$ParamFns 
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//... 

private: 

double m_someVar; 
$ParamAttrs 

5 // ... 

>; 

//... 

SParamlmpls 

} // End namespace 

10 CPlusPlusEnd 

[00314] Note that a custom type name-number pair is declared. An array parameter 
of that custom type may be used to achieve the same effect as the above ParamGroup of 
parameters. The technique presented above is a way to avoid the necessity of declaring a 
custom type. 

15 [00315] Figure 13 illustrates a method for developing a test program according to 
an embodiment of the present invention. The method describes a test plan file 1302 in a 
test program language (TPL), where the test plan file describes at least one test the test 
program. The method also describes a test class file 1306 in a system program language 
(SPL) and a corresponding pre-header file 1304 of the test class file in the TPL, where the 

20 test class file describes an implementation of the at least one test of the test program. In 
this implementation example, the SPL is the C/C++ program language. A person skilled 
in the art would recognize that other system program languages may be used instead of 
the C++ program language. Note that one of the benefits of describing the test plan file in 
the TPL is to allow it to be closer to the problem domain. The TPL separates the burden 

25 and complexity of system programming from the test plan developers. 

[00316] According to an embodiment of the present invention, a pre-header file has 
the following declarations: 

• Optional Imports, as in other TPL files. 

• A name of the test class. 

30 • An optional TestClass DLL keyword, which specifies the DLL for the 

implementation of this class. 

• An optional list of public bases. 

• A parameters section specifying the parameters of this test class. 
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• A template section providing an in-lined template for the test class. 

[00317] The parameters section of a pre-header file is used by the test class 
developer to specify parameters for the test class file 1306, thus creating user-defined tests. 
These are members of the test class file that the user can specify in terms of instances, 
thus providing the user with finer control of the testing operation. For instance, a test 
class developer may declare a user-defined parameter TraceLevel, which may be specified 
by a user in order to control the level of tracing, such as verbose or terse, when the test 
executes. 

[00318] There are three types of entities that can be declared within the parameters 
section of a test class file: 

• Enumerations using the Enum keyword. Note that the Enum keyword is used to 
define a test class enumerated type. The test class file can then have parameters of 
this enumerated type. This can also be used by a GUI to construct a drop-down 
list of values allowed for the parameter. 

• Parameters using keywords such as Integer, PList, etc. specifying the parameter 
type, where the type is a valid TPL type. 

• Groups of parameters using the ParamGroup keyword. The ParamGroup keyword 
is used to collect a number of different parameters as a group, similar to a C++ 
class. 

[00319] Individual parameters of the test class file can be declared within the 
parameters section. Parameter declarations have a syntax which declares the type of the 
parameter, its name, and various properties of the parameter. The following is an 
example of a set of parameters: 

• Cardinality: This indicates the number of parameters of this type that is supported. 

• Attribute: The name of the C++ variable to use as the store for parameter value(s) 
of this type. 

• SetFunction: The nature of the function to use for setting a value for this 
parameter. The optional keyword "[implement]" following the function is made 
available as an inline method in the class header (inserted at the point indicated by 
$ParamFunctionImplementations). Otherwise, the user is responsible for 
providing an implementation of the function. 
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• Description: A string literal can be used, for example, as a tool tip by a GUI to 
provide help during runtime modification of the parameter. The C++ member 
function generated in the custom class for a parameter named Foo is "OFC: String 
getFooDescriptionQ const". This function returns the specified string. 
5 • GUIType: This optional keyword specifies a string to be passed to a GUI when an 

XML descriptor is generated for an instance of this test class. It enables the GUI 
to display this parameter value in a special way. 

[00320] The template section of the pre-header specifies source code that is to be 
inserted into the header file 1312. It gives the test class developer direct control over the 
10 C++ header generated for this test class file. The template section is located between the 
keywords CPlusPlusBegin and CPlusPlusEnd. It uses various replacement indicators 
(such as SImportDeclarations, $ClassName, SParamArray Types, 
$ParamFunctionDeclarations, SParamAttributes, $ParamFunctionImplementations, etc.) 
which specify the locations for various declarations. 

1 5 [00321] The method applies a TPL compiler 1308 to compile the test plan file 1 302 
and the pre-header file 1304. The TPL compiler compiles the test plan file 1 302 to form a 
derived test plan file 1310 described in the C++ language. The TPL compiler performs at 
least two important functions while compiling the test plan file. First, it translates the test 
plan file from a TPL description to a SPL description. Second, it validates the test plan 

20 file using the pre-header file. In particular, it checks for semantic errors within the test 
plan file. In addition, it verifies the attributes of the test entities. It ensures the attributes 
of the test entities are declared and exist in either the test plan file or the pre-header file. 
Furthermore, it verifies functional calls and their corresponding parameters of the test 
plan. It ensures that the function calls of the test plan file exist in the test class 

25 implementation and that the parameters of the functional calls are defined. 

[00322] Similarly, the TPL compiler 1308 compiles the pre-header file 1 304 to 
form a header file 1312 described in the C++ language. The TPL compiler 1308 inserts in 
the header file 1312 parameters described in the parameters section of the pre-header file 
1304. In addition, the TPL compiler 1308 inserts in the header file 1312 source code 
30 referenced in the template section of the pre-header file 1 304. The header file 1312 serves 
two purposes. First, it is used by a SPL compiler 1314 to generate a test class object file 
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1316. Second, it is referenced by the SPL compiler 1314 to generate a test plan object file 
1318. 

[00323] Finally, the test class object file 1 3 1 6 and the test plan object file are linked 
by a linker 1320 to generate an executable test plan DLL file (TPL.DLL) and an 
5 executable test class DLL file (TCL.DLL) of the test program 1322. 

C5. Custom Function Declarations 

[00324] This allows the user to call custom functions when a flow transition takes 
place. Custom functions are declared through pre-header as follows: 



# 

10 # File MyFunctions.ph 

# 

# Parameterization specification pre-header for MyFunctions 
# 

15 Version 1.0; 

Functions = MyFunctions; # The name of this group of functions 

# Declare the following C++ function in the 

20 # MyFunctions namespace to determine the minimum 

# of two values. 

# // Return the minimum of x, y 

# double MyRoutines::Min 

# (ITestPlan* pITestPlan,int& x, int& y); 
25 Integer Min(Integer x, Integer y); 

# Declare the following C++ function in the 

# UserRoutines namespace to return the average of 

# an array. 

30 # // Return the average of the array 

# double MyRoutines::Avg 

# (ITestPlan* pITestPlan, double* a, const int a_size); 

# The C++ function will be called with a and a'Length 
Double Avg(Double a[]); 

35 

# Declare the following C++ function in the 

# UserRoutines namespace to print the dut id 

# and a message 

# // Return the average of the array 
40 # double MyRoutines::Print 

# (ITestPlan* pITestPlan, String* msg, unsigned int& 
dutld); 

# The C++ function will be called with a and a'Length 
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Void Print(String msg, Unsignedlnteger dutld); 



[00325] Typically a C++ section needs to be provided for the above declarations, as 
the compiler will expand these declarations in a standard way. The user is of course 
5 responsible for the C++ implementation of these functions. Note that all of the above 
functions will presumably take an ITestPlan pointer as an implicit first parameter. This 
pointer provides the function writer access to stateS in the TestPlan. For instance, the 
function writer could use the ITestPlan interface to access the current Flow, the current 
Flowltem in the flow, the current Result clause, values of UserVars, and other such 
10 information. Certain tester defined functions are available for use in the file Functions.ph: 



Version 1.2.3; 

# 

# File Functions.ph 
15 # 

Functions = Functions; # The name of this group of functions 

# Declare the following C++ function in the 

# Functions namespace 

20 

# Returns the ID of the current DUT being tested by the 

# caller. 

Unsignedlnteger GetDUTID(); 
25 C++ for Custom Function Declarations 



[00326] The C++ code that would be generated by compiler for MyFunctions 
above is to simply declare some functions in the MyFunctions namespace: 

namespace MyFunctions 

{ 

30 double Min(ITestPlan* pITestPlan, int& x, int& y); 

double Avg(ITestPlan* pITestPlan, double* a, const int a_size); 
void Print(IT estPlan* pITestPlan, char* Msg, unsigned int dutID); 

} 

[00327] These functions will be callable from a flow. 
35 C6. Custom Flowables 



[00328] It is also possible to create a pre-header implementing the C++ IFlowable 
interface using the pre-header. This enables a user to define custom flowables that can be 
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run in a Flowltem. Shown below is a pre-header for the user-defined Flowable 
MyFlowable: 



10 



# 

# File MyFlowable.ph 

# 

# Parameterization specification pre-header for MyFlowable 
# 

Version 1.2.4; 

FlowableClass = MyFlowable; # The name of this custom class 



# The parameters list: 
Parameters 

15 { 

# The following declaration specifies that a MyFlowable has 

# - 1 optional parameter Intl of type Integer 

# - [represented by C++ type int] 

# -stored in a member named m_intlVal 
20 # - a function to set it named setlntl Val. 

Integer Intl 

{ 

Cardinality = 0-1; 
Attribute = m_intl Val; 
25 SetFunction = setlntl Val; 

} 

# The following declaration specifies that a MyFlowable has 

# - 1 mandatory parameter Int2 of type Integer 
30 # - [represented by C++ type int] 

# - stored in a member named m_int2Val 

# - a function to set it named setInt2Val. 
Integer Int2 

{ 

35 Cardinality = 1 ; 

Attribute = m_int2Val; 
SetFunction = setInt2Val; 

} 

# The following declaration specifies that a MyFlowable has 
40 # - one or more parameters of type String 

# - [represented by C++ type Tester:: String] 

# - stored in a member named m_stringArrVal 

# - a function to set it named addStringVal. 
String Stringltem 

45 { ' 

Cardinality = 1-n; 
Attribute = m_stringArrVal; 
SetFunction = addStringVal; 
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} 

# The following declaration specifies that a MyFlowable has 

# - A single PList parameter 

# - [represented by the C++ type Tester: :PList] 

# - stored in a member named m_plist 

# - a function to set it named setPListParam 
PList PListParam 

{ 

Cardinality = 1; 
Attribute = m_plist; 
SetFunction = setPListParam; 

} 

} 
# 

# The section below is part of the Pre-Header which is an escape 

# into C++ code. 
# 

# Everything in this section will be reproduced verbatim in the 

# generated header file, except for "$CIass". "Sine", 

# "$ParamAryTypes", "$ParamAttrs", "$ParamFns" and 
"$ParamImpls". 

# 

# Note that no comments beginning with the '#' character are 
supported 

# within the following section. 

# 

CPlusPlusBegin 
Sine 

namespace 
{ 

class SClass 
{ 

// Array types for parameters storage: 

SParam AryTy p es 

public: 

virtual void preExec(); 

virtual void exec(); 

virtual void postExec(); 

SParamFns 

//... 
private: 

double m_someVar; 

SParamAttrs 

II ... 

}; 

// ... 

SParamlmpls 
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} // End namespace 
CPlusPlusEnd 

[00329] There are several classes implementing the IFlowable interface. These 
include: 

5 1 . Flows for program loading which will check whether a test plan can be 

executed within the current tester configuration. 

2. Flows for pattern loading which will load specific patterns and pattern lists. 

3. Flows for initialization which will put hardware and software in a known 
state, load global variables, and do other initialization and validation 

10 functions. 

4. Other generally useful test flows. 
CI. Custom Types 

[00330] The discussion on Test class parameterization earlier only allowed for test 
class parameters to be of known types, viz., elementary types and tester-defined types 

15 such as PLists, and TestConditions. For user flexibility, it is important to provide type 
extensibility, whereby types (that are unknown a-priori to the compiler) can be created 
and used. Custom types (CTs) will be defined in the Custom Types. These can be used to 
define types corresponding to C-language structs (also referred to as Plain Old Data types, 
or PODs, which are quite different from their namesakes in C++) as well as for types 

20 corresponding to C-language typedefs for function signatures. A separate file with user 
types will have the extension .ctyp. Here is an example of a user types declaration in 
accordance with the preferred embodiment of the present invention: 



# 

# File MyCustomTypes.ctyp 
25 # 



Version 1.0.0; 

CustomTypes 

30 { 

# A structured Plain-Old-Data type 

Pod Foo 

{ 

String SI; # String is a standard type 
35 Integer II; # ... and so is Integer 
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String S2; 

} 

# Another structured type using Foo 
Pod Bar 

{ 

Foo Fool; 
String SI; 
Foo Foo2; 

} 

# 

# A pointer to a function. 

# Return type: Integer 

# Parameters: Integer, Integer 

# 

Routine BinaryOp(Integer, Integer) Returns Integer; 

# 

# Another pointer to a function. 

# Return type: Void 

# Parameter: Integer 
# 

Routine UnaryOp(Integer) Returns Void; 

# 

# A pointer to a function that takes 

# no parameters and does not return a value. 

# 

Routine NullaryOpQ Returns Void; 



C++ for Custom Types 

[00331] The CustomTypes declaration presented above will be translated by the 
compiler into the following C++ code: 

namespace CustomTypes 
{ 

struct Foo 
{ 

Tester: .-String SI; 
int II; 
Tester:: String S2 

}; 

struct Bar 
{ 

Foo Fool; 
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Tester: -.String SI; 

Foo Foo2; 

}; 

typedef int (*BinaryOp) (int&, int&); 
5 typedef void (*UnaryOp)(int); 

typedef void (*NullaryOp)0; 

} 

[00332] Objects of these types can be passed to Test classes as parameters, as 
shown next. 

1 0 Using Custom Types as Test Class Parameters 

[00333] Consider the case where the user has an extension to a test, which needs to 
be initialized with — in addition to pattern lists and test conditions — other class objects, 
as well as arbitrary (i.e., user-defined) objects that are defined within a file containing 
Custom Types (i.e., a xtyp file). For example, suppose the user wants to use the CTs 
1 5 defined in the file MyTestCTs.ctyp: 

# File MyTesetCTs.ctyp 
Version 1.0; 

CustomTypes 

20 { 

Pod Foo 

{ 

String name; 
PList patteraList; 

25 } 

Pod Bar 

{ 

Foo someFoo; 
30 Double dVal; 

} 

Routine BinaryOp(Integer, Integer) return Integer; 

} 

35 [00334] All that the user needs to do to use the above types is import the above file 

in his test class pre-header. Since the compiler interprets CTs that are so defined, the 
definitions for Foo and Bar are therefore available to it when it is processing the test class 
pre-header. Moreover, the compiler defines two C-language structs, struct Foo and struct 
Bar, corresponding respectively to the types Foo and Bar above, the definitions for which 
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are placed in the file myTestCTs.h. The Import statement for myTestCTs.ctt causes the 
file myTestCTs.h to be #include-d in the generated test class C++ header. The following 
example illustrates this process. First, consider the declaration for the test in the test plan 
(the declarations for pattern lists and test conditions have been omitted for clarity): 

5 

Import MyFunctions.ph; 
Import MyCustomTypes.ctyp; 

# The Custom Vars block defines variables of the Custom 
10 # types defined earlier. 

CustomVars 

{ 

Bar barl = 
15 { 

{ "This is a Foo", somePatList }, # someFoo 
3.14159 #dVal 

} 
# 

20 # A function object that is a binary operator. 

# The name on the right hand side of the assignment 

# is a routine declared in MyFunctions, for which, 

# of course, the user has to provide an implementation. 

# 

25 BinaryOp bopl =MyFunctions.Min; 



Test MyFancyTest MyTestl 
{ 

30 

BarParam = barl; 
BinaryOpParam = bopl; 

} 

35 [00335] In the above example, a CustomVars block is included in a test plan. A 
separate file with customization variables will have the extension .cvar. The user would 
write a pre-header for MyFancyTest that supports the above parameterization as follows 
(the parameterization declarations for pattern lists and test conditions have been omitted 
for clarity): 



40 # 

# File MyFancyTestph 

# 
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# Parameterization specification pre-header for MyFancyTest 
# 



Version 1.0.2; 

Import MyCustomTypes.ctyp; 
Import FunctionalTestph; 
TestClass = MyFancyTest; 
PublicBases = FunctionalTest; 



# For CTs used in MyFancyTest 

# For base class FunctionalTest 

# The name of this test class 

# List of public base classes 



# The parameters list: 
Parameters 

{ 

# The following declaration specifies that a MyFancyTest has 

# - an optional array of parameters of custom type Bar 

# - [represented by C++ type CustomTypes::Bar] 

# - stored in a member named m_barsArray 

# - a function to set it named addBarParam. 

# An implementation will be generated for addBarParam. 
Bar BarParam 

{ 

Cardinality = 0-n; 

Attribute = m_barsArray; 

SetFunction = addBarParam [Implement]; 

} 

# The following declaration specifies that a MyFancyTest has 

# - an optional parameter of custom type BinaryOp 

# - [represented by C++ type CustomTypes::BinaryOp] 

# - stored in a member named m_binaryOp 

# - a function to set it named setBinaryOpParam. 

# An implementation will be generated for setBinaryOpParam. 
BinaryOp BinaryOpParam 

{ 

Cardinality = 0-1; 

Attribute = mbinaryOp; 

SetFunction = setBinaryOpParam [Implement]; 



CPlusPlusBegin 
$Inc 

namespace 
{ 



class SCIass 
{ 
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SParamAry Types 

public: 

virtual void preExec(); 
virtual void exec(); 
5 virtual void postExecO; 

SParamFns 
II ... 
private: 

double msomeVar; 
10 SParamAttrs 

//... 

}; 

//... 

15 SParamlmpls 

} // End namespace 
CPlusPlusEnd 

C++ for Custom Test Classes using Custom Types 

[00336] Finally, once the compiler has processed this pre-header file, it will create 
20 the following C++ header file for the MyFancyTest class, MyFancyTest.h: 

#include <MyCustomTypes.h> 
#include <ITest.h> 
#include <FunctionalTest.h> 

25 namespace 

{ 

class MyFancyTest : public ITest, 

public FunctionalTest 

{ 

30 public: 

typedef std::vector<CustomTypes::Bar *> BarAryt; 

public: 

virtual void preExec(); 
virtual void exec(); 
35 virtual void postExec(); 

public: 

void setName(OFCString &name); # Automatic for all tests 
void setPatternTree(PatternTree *); 
void addTestCondition(TestCondition *); 
40 void addBarParam(CustomTypes::Bar 

void setBinaryOpParam(CustomTypes::BinaryOp *); 



private: 
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double m_someVar; 
private: 

OFCString mname; # Automatic for all tests 
PatternTree *m_pPatList; 
5 TestConditionPtrsAry_t m_testCondnsArray; 

BarAry_t m_barsArray; 
BinaryOp *m_binaryOp; 

}; // End class MyFancyTest 



inline void 

MyFancyTest::addBarParam(CustomTypes::Bar *arg) 
{ 

m_barsArray.push_back(arg); 
15 return; 

} 

inline void 

MyFancyTest::setBinaryOpParam(CustomTypes: :BinaryOp *arg) 
{ 

20 m_binaryOp = arg; 

return; 

} 

} // End namespace 
25 C8. Parameterization 

[00337] As seen above, a pre-header for a Test class, custom Flowable class, or 
custom function definitions offers limited introspection into the class/functions through a 
parameterization specification section. The compiler uses this section to generate the 
parameterization interface for the class/function (and generate the class/function header 
30 itself). For Test classes and Flowable classes, it also uses this section to subsequently 
generate the calls in the Test Plan code to initialize an instance of that class. The 
following points concerning pre-headers and corresponding declaration should be noted: 

1 . Every Test or custom Flowable class definition is preferably specified in a 
' pre-header. The Parameters block in the pre-header is preferably the only 
35 place where the parameters list for such a class can be specified. (Thus, as 

a corollary, the "standard" parameters for a Test, such as pattern list and 
test condition specifications, also need to be included in the pre-header's 
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Parameters block; this allows all parameters, standard and CTs, to be 
treated uniformly.) 

2. All parameters defined as non-optional (i.e., with a non-zero cardinality) in 
the pre-header for a Test or Flowable class should be initialized in the Test 
block or Flowable block declaration for an instance of that class. 



3. The objects used for initialization of parameters in the Test/Flowable block 
should have been defined previously. 

4. The replacement indicators $Class, $Inc, $ParamAryTypes, $ParamFns, 
$ParamAttrs and $ParamImpls must appear at the exact locations within 
the user code section of the pre-header that the user intends the 
corresponding generated code to be inserted at in the generated class 
header file. These should appear exactly once, since specific code is 
generated for each. 

5. The name of a parameter specification in the Parameters block of the pre- 
header (such as PListParam, TestConditionParam or BarParam in the 
examples above) is the name of the parameter to be used in the declaration 
of an instance of that class. 

6. The following are the semantics of the descriptors used in a parameter 
specification: 

a. Cardinality: This indicates the number of parameters of this type 

that will be supported. The following are the possible values in one 
embodiment: 

i. 1: This parameter is mandatory, and should be specified 
exactly once. This parameter will be maintained as a 
pointer to an object of the type of the parameter. 
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u 0-1: This parameter is optional; if specified, it must be 

specified only once. This parameter will be maintained as a 
pointer to an object of the type of the parameter. 

iii 1-n: This parameter is mandatory. Moreover, multiple 
values can be specified for this. The values will be stored in 
the order of specification. 

iv 0-n: This parameter is optional. Multiple values can be 
specified for this. The values will be stored in the order of 
specification. 

Note that for () and () above, all specified values will be stored in 
an STL vector<>, templated on a pointer to the type of the 
parameter. The type of this vector will be defined and inserted at 
the point indicated by $ParamAryTypes. The access level for these 
type definitions is always public. 

Attribute: The name of the C++ variable to use as the store for 
parameter value(s) of this type. The name will be reproduced 
verbatim, as a private data member of the C++ class, and must 
conform to the requirements for a C++ identifier. Note that the 
type of this attribute is: 

i. A pointer to the type of the parameter, if only single values 
are permitted; 

ii. An STL vector<>, templated on a pointer to the type of the 
parameter, if multiple values are permitted (see () above). 

Note that the attributes hold references to objects created and 
populated by the Test Plan, and do not own these objects. The 
lifetime of the objects are always managed by the Test Plan itself. 

SetFunction: The name of the function to use for setting a value for 
this parameter. The following points should be noted: 

i. The name will be reproduced verbatim, and hence, must 
conform to C++ language requirements. 
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ii. The access level of the function is always public. 

iii. The return type is always void. 

iv. The function always takes only a single argument, of type 
pointer-to-parameter-type. 

[00338] Note that a value is always set singly; i.e., for parameters that allow 
specification of multiple values, the generated code in the Test Plan will call this function 
repeatedly, once for every value specified, each of which will be added to an STL vector 
(as described above). 

[00339] The optional keyword "[implement]" following the function name 
indicates that a trivial implementation for this function will be made available as an inline 
method in the class header (inserted at the point indicated by $ParamImpls). Otherwise, 
the user is responsible for providing an implementation of the function. 

d. Description: A string literal that is a tooltip which will be used by a 
GUI tool to provide help during runtime modification of this 
parameter. The C++ member function generated in the custom 
class for a parameter named Xxx will be 

String getXxxDescription () const; 

The function will return the specified string. 

Test Plan Example with Customization 

[00340] Shown below is the test plan example embellished with some 
customization: 



# 

# File MyCustomizedTestPlan.tpl 
# 



Version 0.1; 

# 

# Imports as before ... 

# The following import is implicit, but can be explicitly 

# provided. 

Import FunctionalTestph; 
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# Import for MyFlowables, MyFunctions and Functions 
Import MyFlowables.ph; 

Import MyFunctions.ph; 
Import Functions.ph; 

# 

# Start of the test plan 

# 

TestPlan Sample; 

# This block defines Pattern Lists file-qualified names and 

# Pattern List variables that are used in Test declarations. 

# The file-qualified names refer to pattern lists in the named 

# files. The variables refer to String variables which will 

# hold the pattern list names at run time. User defined Flowable 

# objects could set the values of these variables through an 
#API. 

PListDefs 

{ 

# File qualified pattern list names 
pllA.plist:patlAlist 5 
pl2A.plist:pat2AList, 

# Pattern list variables 
plistXxx, 
plistYyy, 

plistZzz 

} 



# SocketDef, UserVars declaration as before ... 

# Declarations of TestConditions TClMin, TClTyp, TClMax, 

# TC2Min, TC2Typ, TC2Max as before ... 

# 

# Declare a FunctionalTest. "FunctionalTest" refers to a C++ 

# test class that runs the test, and returns a 0, 1 or 2 as 

# a Result. The Test Condition Group TCG1 is selected with 

# the "min" selector by referring to the TClMin TestCondition. 

# 

# Note that compiler can compile this because of the imported 

# FunctionalTest.ph file. 

# 

Test FunctionalTest MyFunctionalTestlMin 
{ 

PListParam = patl AList; 
TestConditionParam = TClMin; 
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} 
# 

# Additional FunctionalTest declarations for the following, as before 

# MyFunctionalTestlTyp 

# MyFunctionalTestlMax 

# MyFimctionalTest2Min 

# MyFunctionalTest2Typ 

# MyFunctionalTest2Max 
# 

# Here is a declaration of MyFlowable. It uses a PatternList variable 

# plistXxx which is initialized by the flowable prior to use here. 

# 

# Compiler can compile this because of the imported MyFlowables.ph 
file: 

Flowable MyFlowable MyFlowable 1 

{ 

Intl = 10; 
Int2 = 20; 

Stringltem = "Hello World"; 
PListParam = plistXxx; 

} 

# Counters for PassCount and FailCount as before ... 

# Flows as before. Flows FlowTestl and FlowTest2 are 

# unchanged from the previous example. 
Flow FlowTestl 

{ 

} 

Flow FlowTest2 
{ 

#... 

} 
# 

# Now FlowMain, a main flow, can be presented. It 

# implements a finite state machine that calls FlowTestl 

# and FlowTest2 as below: 

# 



# 

#- 






Result 0 




Result 1 


# 


FlowMain_ 


1 


FlowMain_ 


2 


return 1 


# 


FlowMain_ 


2 


FlowMain 


"3 


return 1 


# 


FlowMain_ 


3 


FlowMain 


4 


return 1 


# 


FlowMain_ 


4 


FlowMain 


5 


return 1 


# 


FlowMain_ 


5 


return 0 




return 1 
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# 

# Where the IFlowables run by each Flowltem are: 
# 

# Flowltem IFlowable that is run 
5 # 

# FlowMain_l MyFlowablel 

# FlowMain_2 DatalogStartFlow 

# FlowMain_3 FlowTestl 

# FlowMain_4 FlowTest2 

10 # FlowMain_5 DatalogStopFlow 

# 

Flow FlowMain 
{ 

# 

1 5 # The first declared flow is the initial flow to be 

# executed. It goes to FlowMain_InitializationFlow 

# on success, and returns 1 on failure. 

# 

Flowltem FlowMain_l MyFlowablel 

20 { 

Result 0 

{ 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 
25 # A user function call 

MyFunctions.Print ("Passed MyFlowablel", 
Functions.GetDUTID()); 

GoTo FlowMain_2; 

} 

30 

Result 1 

{ 

Property PassFail = "Fail"; 
IncrementCounters FailCount; 
35 # A user function call 

MyFunctions .Print("Failed MyFlowable 1 ", 

Functions.GetDUTIDO); 
SetBin SoftBins."3GHzLeakage"; 
Return 1 ; 

40 } , 

} 

# 

# Goes to FlowMain_3 on success 
45 # and returns 1 on failure. 

# 

Flowltem FlowMain_2 DatalogStartFlow 

{ 

Result 0 
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Property PassFail = "Pass"; 
IncrementCounters PassCount; 
# A user function call 

MyFunctions.Print("Passed DatalogStartFlow", 

Functions.GetDUTIDO); 
GoTo FlowMain_3; 



10 Result 1 

{ 

Property PassFail = "Fail"; 
IncrementCounters FailCount; 
MyFunctions.Print("Failed DatalogStartFlow", 
15 Functions.GetDUTIDO); 

Return 1 ; 

} 

} 

20 # This Flowltem calls the previously defined FlowTestl 

Flowltem FlowMain_3 FlowTestl 
{ 

Result 0 

{ 

25 Property PassFail = "Pass " ; 

IncrementCounters PassCount; 

# A user function call 
MyFunctions.Print("Passed FlowTestl", 

Functions.GetDUTIDO); 
30 GoTo FlowMain_4; 

} 

Result 1 

{ 

35 Property PassFail = "Fail"; 

IncrementCounters FailCount; 

# A user function call 
MyFunctions.Print("Failed FlowTestl ", 

Functions.GetDUTIDO); 
40 SetBin SoftBins."3GHzCacheFail"; 

Return 1; 

} 

} 

45 # This Flowltem calls the previously defined FlowTest2 

Flowltem FlowMain_4 FlowTest2 

{ 

Result 0 

{ 
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Property PassFail = "Pass"; 
IncrementCounters PassCount; 

# A user function call 
MyFunctions.Print("Passed FlowTest2", 

Functions.GetDUTID()); 
GoTo FlowMain_5; 

} 

Result 1 

{ 

# FlowTestl passed, but FlowTest2 failed 
Property PassFail = "Fail"; 
IncrementCounters FailCount; 

# A user function call 
MyFunctions.Print("Failed FlowTest2", 

Functions.GetDUTID()); 
SetBin SoftBins."3GHzSBFTFail"; 
Return 1; 

} 

} 

Flowltem FlowMain_5 DatalogStopFlow 
{ 

Result 0 

{ 

# All Passed! 

Property PassFail = "Pass"; 
IncrementCounters PassCount; 

# A user function call 
MyFunctions .Print("Passed all ! ", 

Functions.GetDUTIDO); 
SetBin SoftBins."3GHzAllPass"; 
Return 0; 



Result 1 

{ 

# FlowTestl and FlowTest2 passed, 

# but DatalogStopFlow failed 
Property PassFail = "Fail"; 
IncrementCounters FailCount; 

# A user function call 

MyFunctions.Print("Failed DatalogStopFlow", 
Functions.GetDUTIDO); 

Return 1; 

} 

} 
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[00341] The following points need to be noted about the above code: 

1 . The PListDefs section here has some PList names and also some PList 
variables. The PList names are names that can directly be used in tests. 
The PList variables are variables which can be used in tests, and whose 

5 value is bound at runtime to actual PLists by code in a customized 

Flowable. 

2. The PListDefs section is optional. If not present, its contents will be 
inferred by compiler from the various Test declarations. If present, it must 
declare all of the used PList parameters of Tests, though it may declare 

10 more. 

3. A runtime API will be available to assign values to PList variables. The 
TestPlan class will have a function: 

Status SetPListVariable(const Tester: :String& varName, 

const Tester: :String& fileQualifiedPListName); 
1 5 The Flowable will be able to use the above function to bind a 

PListVariable to a particular PList. 

4. User functions and functions can be called in Flowltems just prior to a 
transition, which is either a transfer of control to another Flowltem, or a 
return. 

20 C++ for User Function Calls 

[00342] With the exception of invoking custom function calls in flows, C++ code 
that would be generated by the compiler has been shown for the various customization 
techniques presented earlier. User function calls in a Flowltem are preferably handled by 
an IUserCalls member of each Flow. Each Flow preferably has a member of the interface 
25 IUserCalls which exports a single virtual member function, as shown below. 

class IUserCalls 
{ 

public: 

virtual void exec(const String& flowItemName, 
30 unsigned int result) = 0; 

}; 
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[00343] When a Flow with user function calls is encountered, the Flow gets 
populated with an instance of a class that implements the above interface. For example, 
in FlowMain in the example in the flow will be populated with an instance of the 
following class: 

class FlowMainJUserCalls : public IUserCalls 
{ 

public: 

virtual void exec(const String& flowItemName, 
unsigned int result) 

{ 

if (flowItemName = "FlowMain_l") 
{ 

II ... 

} else if (flowItemName == "FlowMain_2") 
{ 

II ... 

} else if (flowItemName == "FlowMain_3") 
{ 

switch (result) 

{ 

case 0: 

MyFunctions: :Print("Passed FlowTestl ", 

Functions::GetDUTID0); 

return; 
case 1: 

MyFunctions: :Print("Failed FlowTestl 

Functions : :GefDUTID()); 

return; 
default- 
return; 

} 

else if (flowItemName == "FlowMain_4") 
II ... 

else if (flowItemName = "FlowMain_5") 
//... 

. } 

}; 

[00344] The FlowItem::execute() operation knows the name of the flow item. 
Before it returns with the pointer to the next flow, it will call IUserCalls: :exec() for the 
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enclosing flow, passing its own flow item name, and the value of the current result. This 
will cause the above code to be executed, invoking the needed user defined functions. 

C9. Test Program Compilation 

[00345] As explained above, the Test Plan description file specifies the objects 
5 used in a test plan and their relationships to one another. In one embodiment, this file is 
translated to the C++ code that will be executed on the Site Controller in the form of an 
implementation of a standard interface ITestPlan. This code can be packaged into a 
Windows dynamic link library (DLL) which can be loaded onto the Site Controller. The 
Test Program DLL is generated to have standard known entry points that the Site 
10 Controller software can use to generate and return the TestPlan object it contains. 

Construction from a Test Plan Description 

[00346] The process of conversion from a test plan description to an 
implementation of ITestPlan is accomplished by the test program compiler 400. This 
process occurs in two phases: translation and compilation. 

1 5 [00347] In the translation phase 402, the compiler 400 processes a test plan file 

(and the various other files it imports), as well as the pre-headers for all the test types used 
in the test plan. In this phase, it creates the C++ code for the Test Plan object and the C++ 
headers for the test types encountered, along with all other supporting files, such as 
MSVC++ (Microsoft Visual C++) workspace and project files, DLL "boilerplate" code, 

20 etc. The compiler 400 inserts file and line directives into the generated code to ensure 
that compile-time error messages refer back to the appropriate location in the description 
file instead of pointing into the generated code. 

[00348] In the compilation phase, which occurs after the compiler has created the 
necessary files, a standard compiler 404, such as an MSVC++ compiler, is invoked to 
25 compile the files and link them into a DLL. 

[00349] The compiler takes, as input, a valid test plan file (and all related files), and 

generates, as necessary, a TestPlan file and all other files represented by "Import" 
directives in the test plan file. In addition, it generates a MSVC++ "Solution" to build the 
Test Plan DLL. For example, if the main file (MyTestPlan.tpl) included Timingl .tim to 
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incorporate timing information, then the compiler would create (among others) the 
following files: 

MyTestPlan.h 
MyTestPlan.cpp 
5 Timing l.cpp 

MyTestPlan.sln (MSVC++ "Solution" file) 
MyTestPlan.vcproj (MSVC++ "Project" file) 

[00350] After all files are created (or updated), the compiler invokes the MSVC++ 
10 application, specifying the "Solution" it created, and builds the DLL. Any errors and/or 
warnings would be shown to the user. 

[00351] If, after building the Test Plan, the user made a change to Timingl .tim, the 
user would then invoke the compiler, passing it MyTestPlan.tpl. The compiler would 
recognize (by timestamp information) that the main test plan file is unchanged, so that 

1 5 MyTestPlan.h/.cpp would not be recreated. However, while processing the main test plan 
file, it would see that the Timing.tim file has changed. Therefore, it would recreate the 
Timing l.cpp file, and invoke the MSVC++ application to rebuild the DLL. This avoids 
recompiling MyTestPlan.cpp, and only compiles Timing l.cpp and re-links the DLL. This 
approach will be especially useful in cutting down re-compile and re-link times for large 

20 test plans that take a significant amount of time to compile. 

D. Running the Test Program 

[00352] The Site Controller software loads the Test Program DLL into its process 
space and calls a "factory" function within the DLL to create an instance of the Test Plan 
object. Once the Test Plan object has been created, the Site Controller software can then 
25 execute the test plan or interact with it in any other way necessary. 

Non-Interactive Builds 



[00353] To most C++ software developers in the Windows environment building 
an application (or a DLL, or Library, etc) means bringing up a development environment 
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(MS Visual C++, Borland C++, or similar), editing code, and (often) pressing a button to 
build the product. 

[00354] The test environment of an embodiment of the invention will have a 
similar set of activities. Test Plan developers will need to edit code and build their Test 
5 Plans. However, tester will not require the Test Plan developer to bring up a C++ 
development environment in order to produce the resulting Test Plan DLL. 

[00355] In order to accomplish this the present invention employs the concept of a 
non-interactive build. A non-interactive build is defined as a build that uses MS Visual 
C++ in a non-interactive mode. Note that this still allows other tools to be used 
10 interactively to manage such a build. The only implication is that Visual C++ is used 
non-interactively. 

Assumed Environment 

[00356] Certain assumptions are made about the user's environment. The 
assumptions are: 

15 1 . The Test Plan developer will be developing his Test Plan according to 

above methods and rules. 

2. The Test Plan developer may not have a expert level knowledge of C++. 

3. The Test Plan developer will have access to command- line tools or GUI 
tools to convert file(s) to a Test Plan DLL. 

20 Building Applications Without Buttons 

[00357] Working with MS Visual Studio non-interactively requires one of two 
approaches. The first (and simplest) is to use the command-line interface. The second 
(and more flexible) is to use the Automation interface. This section describes both 
approaches. 

25 Creating the Project 

[00358] In order to use Visual Studio non-interactively one should start with a 
working Solution which contains one or more valid Projects. Unfortunately, this is the one 
task that cannot be accomplished from either a command-line or Automation approach. 
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Neither method provides a mechanism for project creation. However, projects and 
solutions for Visual Studio can be created from a template. Therefore, given a project 
name and a template to start from we can create a solution/project for Visual Studio. 

Populating the Project 

5 [00359] Adding new files to the produced project uses the Visual Studio 

Automation model since the command-line does not support this. We provide two Visual 
Studio macros to add new and existing files to a project. Similar code could be used by 
an external script using an ActiveScript Engine (such as VBScript, JScript, ActivePerl, 
ActivePython, etc) to perform the same tasks.Therefore, our code generation tools could 
10 create new files and, using the Automation Model, add them to the existing Visual Studio 
project. After the files are created they can be updated as necessary by the tools. 

Building the Project 

[00360] Once we have a solution and project in place there are several options to 

using Visual Studio non-interactively to build the Test Plan. The simplest option is to 
15 invoke it from the command-line. Such a command-line would look like: 

devenv solutionFile /build solutionCfg 

where solutionFile is a Visual Studio solution file and solutionCfg is a specific 
configuration applicable to the projects within the solution. Another solution is to use the 
Visual Studio Object Model for Automation. This allows a finer grain of control over the 
20 build and configuration process. As mentioned above, it contains a listing of a Perl script 
to build a project from the command line. This program reads a configuration file which 
specifies projects and configurations to build (as well as other information about the 
projects) and builds them all using the Automation Model. Look at the uses of the 
$msdev object in this script for examples of how to use Automation objects in a script. 

25 Debugger Support 

[00361] .In order for developers of Test classes to verify and debug their work, they 
need access to a debugger that allows them to break into the Site Controller and step 
through their code. Since the code generated by the compiler is C++ which is compiled 
by MSVC++, we use the MSVC++ debugger to debug Test class implementations. Note 
30 that this feature is meant only for Test class developers or others who work directly in 
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C++. Other mechanisms will be provided to test engineers who wish to debug or step 
through the operation of a Test Program without referring directly to the generated C++ 
code. 

System Software Environment 

[00362] This section describes the general software environment for the Tester: the 
locations for the files required by user test plans, mechanisms for specifying alternate 
locations for such files, and the methods for specifying the locations of the test plans and 
module control software. 

Environment Required by Test Plans 

[00363] System standard locations, as well as the runtime configuration of the 
search paths for 

1. pattern lists, 

2. patterns, 

3. timing data, and 

4. test class DLLs 

required by a test plan, may be configured by "environment" variables, as specified by 
environment configuration files. These are text files, with a simple syntax such as: 

Tester_PATOB J_PATH = "patterns\data;D :\projects\SC23\patterns\data" 

[00364] The advantage of having such "environments" defined in text files instead 
of through native OS-supported environment variables is that the implementation is then 
not limited by the common restrictions that OS-supported environment variables have, 
such as maximum string lengths, etc. The following "environment" (setup) variables will 
be used for the entities listed above: 

Pattern lists: TesterJPATLISTJPATH. 
Pattern object files: Tester_PATOBJ_PATH. 

Pattern source files: Tester_PATSRC_PATH (this is optional; please see). 
Timing data files: Tester_TIMING_PATH. 
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Test class DLLs: Tester_TEST_CLASS_LIBPATH. 
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[00365] In order to support special cases, while maintaining useful default behavior, 
we provide three levels of configuration. These are described in increasing order of 
5 precedence: 

[00366] First, a system environment setup file, 

$Tester_INSTALLATION_ROOT\cfg\setups\Setup.env, will specify the default values of 
"environment" variables. If no other configuration mechanism is available, this file will 
be required. In general, it will be available for all test plans run on the system. This file 
10 is created by the Installation and Configuration Management (ICM) system during 
installation, with input from the installer to assign the default values for the three 
variables mentioned above. (Note that besides the system defaults for the above three 
variables, this file will also contain the system defaults for certain other tester 
"environment" variables, as described in the following sub-section.) 

1 5 [00367] Second, an environment setup file may be specified by the user as a 

runtime argument to the test plan. The variables in this runtime configuration will take 
precedence over default definitions. 

[00368] Finally, a test plan may use a special block to specify the enviromnent 
variables to be used in its execution. Variables defined in the test plan will take 
20 precedence over those in the default system file or the user-defined file. 

[00369] In general, all necessary variables should be defined through one of the 
mechanisms described above. If a variable is not defined, a runtime error will occur. 

Other Environment Setups 

[00370] Besides the "environment" variables that are required by user test plans, 
25 the following two "environment" variables are required by the test environment: 

1. Tester JTESTJPLANJLIBPATH: This specifies the search path 
that the System Controller will use for finding a user test plan DLL 
that should be loaded. Note that the same search path will also be 
used for finding user pin description and socket files. The default 
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value for this variable, specified during installation time to the ICM, 
is stored by the ICM in the file 

$Tester_INSTALLATION_ROOT\cfg\setups\Setup.env. 

Tester_MODULE_LIBPATH: This specifies the search path that 
the system will use to load vendor-provided hardware module 
control software DLLs. This information, extracted from the 
Configuration Management Database (CMD), is also stored in the 
file $Tester_INSTALLATION_ROOT\cfg\setups\Setup.env by the 
ICM. 

[00371] Note that while a user can override the value given in the Setup.env file for 
the Tester_TEST_PLAN_LIBPATH variable, the value given in the Setup.env file for the 
Tester_MODULE_LIBPATH should not be changed by the user unless the user wants to 
explicitly change the search path for the vendor-provided hardware module control 
software DLLs. 

Search Path Specification Semantics 

[00372] The following points should be noted about the "environment" variables 
that specify search paths: 

1 . Each should be a semicolon(";")-separated list of directory names 
that the system will search to find a referenced file of a particular 
type. 

2. After initial system lookup of the value of such an "environment" 
variable, any changes made by the user to its value (for example, by 
editing an environment configuration file) will only be registered 
by the system when the user explicitly "informs" the system of the 
need to do so. 

3. Relative pathnames in the search paths will be interpreted as being 
relative to a particular setting of a related environment variable 
(that provides the functionality of defining a root), as paths relative 
to the "current working directory" (CWD) could lead to ambiguous 
results, since the notion of a CWD in a distributed environment — 
such as the one in which the tester works — might not be what the 
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user intuitively expects it to be. This related environment variable, 
which designates the root that all relative pathnames in the search 
paths will be assumed to be relative to, is the 
'Tester JNSTALLATIONJR.OOT" variable, which gives the 
location of the top-level (i.e., "root") directory of the tester 
installation on a user's system. 

4. The directory entries cannot contain the characters in the set 
[V:*?"o|;]; note that except for the semicolon (";"), all the other 
characters in this set are illegal in Windows file names. The 
semicolon (";") should not be used in search path entries, since it is 
used to demarcate entries in the search path. Note that pathnames 
can have embedded whitespaces, but all whitespaces occurring 
immediately before and after a pathname (i.e., before the first and 
after the last non-whitespace character in the pathname) will not be 
considered to be part of the pathname, and will be ignored. 

5. The search path directories will be searched in the order they are 
encountered in the definition. The first occurrence of a file will be 
the one chosen. 
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E. Test Patterns 

[00373] The efficient management, handling and loading of a very large set of test 
pattern files is an important architectural aspect of the framework of an embodiment of 
the invention. The idea of hierarchical pattern lists is regarded as being an effective tool 
5 in providing tractable conceptualization and ease of use of the system to the end user. 

[00374] The stimulus to a DUT is made available to the test system through test 
vectors. Vectors can generally be categorized as sequential (or linear), scan or 
Algorithmic Pattern Generator (APG)-derived. In the system of an embodiment of the 
invention, test vectors are organized in terms of patterns that are applied to the DUT at 
10 test time. A pattern is represented by a Pattern object in the user's test program. In the 
system, patterns are organized in pattern lists, represented programmatically by pattern 
list objects. A Pattern List object represents an ordered list of patterns or other pattern 
lists. The ordering is implicit in the order of declaration of the list components. Note that 
if only a single pattern is needed, it is required to be encapsulated in a list by itself. 

1 5 [00375] A pattern list object in the user's test program is associated with a pattern 
list file on disk, which contains the actual definition of the pattern list. The contents of a 
pattern list are thus dynamically determined by the contents of the associated disk file 
(more will be said about this later). 

[00376] The definition of a pattern list provides an explicit name for the pattern list, 
20 and identifies an ordered list of patterns and/or other pattern lists through file name 
associations. It also provides for the specification of execution options, which will be 
described in detail after the pattern objects have been described, since the options can be 
applied to both pattern lists and patterns. The pattern list should follow the following 
rules: 

25 file-contents : 

version-info global-pattern-list-definitions 

version-info : 

Version version-identifier ; 

global-pattern-list-definitions : 
30 global-pattern-list-definition 

global-pattern-list-definitions global-pattern-list-definition 

global-pattern-list-definition : 
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global-pattern-list-declaration { list-block } 

global-pattern-list-declaration : 

GIobalPList pattern-list-name options op t 

list-block : 
list-entry 

list-block list-entry 

list-entry : 

pattern-entry ; 
pattern-list-entry ; 
global-pattern-list-definition ; 
local-pattern-list-definition ; 

pattern-entry : 

Pat pattern-name options opt 

pattern-list-entry : 

PList pattern-list-reference options opt 

pattern-list-reference : 

pattern-list-qualified-name 

file-name ': 'pattern-list-qualified-name 

pattern-list-qualified-name : 
pattern-list-name 

pattern-list-qualified-name '. 'pattern-list-name 

local-pattern-list-definition : 

local-pattern-list-declaration { list-block } 

local-pattern-list-declaration : 

LocalPList pattern-list-name options opl 

options : 
option. 

options option 

option : 

[ option-definition ] 

option-definition : 

option-name option-parameters op t 

option-parameters : 
option-parameter 

option-parameters ',' option-parameter 
[00377] The following are the descriptions of undefined non-terminals used above: 

1. version-identifier : A sequence of one or more characters from the set [0- 
9.], where the first character must be a digit. 

2. name : A sequence of. one or more characters from the set [a-zA-Z_0-9], 
where the first character must be from the set [a-zA-Z_] . 
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3. pattern-list-name : A sequence of one or more characters from the set [a- 
zA-Z_0-9], where the first character must be from the set [a-zA-Z_J. 

4. file-name :A valid Windows file name (must be enclosed in double quotes 
if any white-spaces are contained in the file name). Note that this should 

5 be a simple file name, i.e., it should not have a directory component. A 

pattern-list-reference can be either internal referring to a pattern list in the 
same file, or external referring to one in another file. External references 
need to be qualified by a file-name. 

5. option-name : A sequence of one or more characters from the set [a-zA- 
1 0 Z_0-9], where the first character must be from the set [a-zA-ZJ . 

6. option-parameter : A sequence of one or more characters from the set [a- 
zA-Z_0-9]. 

[00378] Pattern list files support comments, which are meant to be ignored by a 
pattern list file parser. Comments start with the '#' character, and extend to the end of the 
15 line. 

El. Rules for Pattern List 

[00379] The static or compile-time rules for pattern lists govern the declaration and 
resolution of names. Names in the pattern list language are declared by global-pattern- 
list-definitions and local-pattern-list-definitions. They are referenced by pattern-list- 
20 references. Below are some rules governing these declarations and references. 

1 . A global-pattern-list-definition or a local-pattem-list-definition declares the 
name of a pattern list. A pattern-list-reference references the name of a 
declared pattern list. The names of global pattern lists are globally known. 
The names of local pattern lists are known only in the list-block in which 

25 they are declared. They can be referred to without qualification directly in 

that list block. In a more deeply nested declaration, a local pattern list will 
need to be referred to by a qualified name. 

2. Local pattern list names are known within the scope of an enclosing pattern 
list, and global pattern list names known within the scope of the system. 

30 For example: 
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GlobalPList Gl 
{ 

LocalPListLl 

{ 

5 LocalPList L2 

{ 

} 

10 GlobalPList G2 

{ 



} 

15 PListL2; # OK. Name L2 is known in this scope 

PList G2 # OK. Name G2 is global 

} 

PList L2; # Error. Name L2 is not known here. 

20 PList LI .L2; # OK. Name LI is known here. L2 is known by 

# qualification. 

PList G1.L1.L2; # OK. Qualification by Gl is not needed but 

# is allowed. 

PList G2; # OK. Name G2 is global 

25 } 

3. Global pattern lists may be defined at an outermost level in a pattern list 

file, or may be defined as nested within an enclosing pattern list. The 
nesting is merely a convenience, however. They are conceptually defined 
as global pattern lists at the outermost level in the file. A nested global 
30 pattern list is semantically equivalent to an outermost (non-nested) global 

pattern list of the same name. So for example: 

GlobalPList Gl 

{ 

GlobalPList G2 ... 

35 } 

is semantically equivalent to: 
GlobalPList Gl 
{ 

PList G2; # References G2 

40 } 

GlobalPList G2 ... 

4 . All global pattern lists are uniquely named. 
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GlobalPList Gl 
{ 

# Note that this is as if declared at the outermost level 

# with a reference to it right here. 
GlobalPList G2 

{ 

} " 

} 

# This declaration will be an error in this or any other file, 

# as the name G2 is already taken. 
GlobalPList G2 # Error. Global name G2 is taken. 

{ 

> ' 

5. Local pattern lists are always have their definitions nested within an 

enclosing pattern list which also determines the scope of the name of the 
local pattern list. Local pattern lists are uniquely named within their 
enclosing pattern list. Local pattern lists are syntactically disallowed from 
occurring at the outermost level in a pattern list file. 

GlobalPList Gl 
{ 

LocalPList LI 

{ 
} 

LocalPList L2 
{ 

LocalPList LI # OK. No local name LI is declared 
directly 

# in the enclosing scope defined by L2. 

{ 
} 

PList LI ; # OK. Refers to L 1 declared in L2 
PList Gl LI ; # OK. Refers to LI declared in Gl . 

} 

# Error. Redeclaring name LI when the enclosing 
• scope 

# defined by Gl already has an LI declared in it. 
LocalPList LI; 

{ 
} 
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} 

6. Each pattern list file contains the definition for one or more global pattern 
lists. This follows directly from the syntax. The outermost level is a 

5 global-pattern-list-definition, and there must be at least one of them. 

7. The pattern-name is a reference to a pattern, following the Pat keyword. It 
references a pattern that is in a pattern file whose name is obtained by 
concatenating a suffix .pat to the pattern name. The file denotes a file that 
will be obtained along a search path defined for patterns. 

10 8. A pattern-list-reference is a reference to a pattern list following the PList 

keyword. The reference consists of an optional filename followed by a 
qualified pattern list name which is just a list of names separated by dots. 
So, for instance, the following could be a pattern-list-reference: 

PList foo.plist:Gl.Ll.L2.L3; 

15 referring to a local pattern list L3 nested in L2 nested in LI nested in a 

global pattern list Gl that is in a file foo.plist. The leftmost name segment 
in the above name is Gl. 

[00380] The leftmost name segment must resolve to either a global pattern list, or 
else to a local pattern list that is visible from the point of reference. 

20 [00381] Name resolution of a pattern-list-reference proceeds as follows: 

1 . Each name segment resolves to a name declared in the context of 
the prefix before it. 

2. If there is a file qualification, the leftmost name segment resolves to 
, a global pattern list declared in the named file. 

25 3. If there is no file qualification, the leftmost name could resolve to a 

local pattern list within the enclosing scope and if that fails then the 
next enclosing scope, and so on, up to an enclosing global scope. 

4. Limiting the searching of scopes to the closest enclosing global 
scope is needed in order to preserve the semantics of global scopes 
30 as if they were declared at the outermost level in the pattern list file. 
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If the nested global scope was (equivalently) textually declared at 
the outermost level, the name resolution search would terminate 
after examining its scope. 

5. If the reference has not been resolved by the prior steps, then the 
5 leftmost name segment can be resolved to a global pattern list 

within this same file. 

6. If the reference has not been resolved by the prior steps, then the 
leftmost name segment can be resolved to a global pattern list 
named in the file by adding the .plist suffix to the leftmost name 

10 segment. 

7. If the reference has not been resolved by the prior steps, then the 
reference is in error. 

[00382] As mentioned earlier, the above rules dictate that the leftmost name 
segment resolves to either a local pattern list that is visible from the point of reference, or 
1 5 else to a global pattern list. 

[00383] The following example illustrates some of these ideas. 

GlobalPlist Gl 
{ 

PList G3; # OK. Refers to a pattern list later in this 

20 file. 

PList G4; # OK. Refers to a pattern list in file 
"G4.plist" 

25 # OK. Refers to Gl in the file "my_plists.plist". 

PList my_plists.plist:Gl; 

# OK. Refers to a pattern list in file "my_plists.plist". 

The 

30 # qualified name refers to a local pattern list named L2 

declared 

# in the scope of a local pattern list named LI declared 
in the 

# scope of a global pattern list named Gl . 
35 PList my_plists.plist:Gl. LI. L2; 

LocalPList LI 
{ 
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LocalPList L2 

{ 

} 

} 

PList LI; # OK. Refers to LI declared in the 
# enclosing scope of Gl 

} 

GlobalPlist G2 
{ 

LocalPList L2 

{ 

} 

GlobalPList G3 

{ 

LocalPList L3 

{ 
} 



PList LI; # Error. No LI declared in this or any enclosing 
# scope; 

# Error. The name L2 is not declared in this scope. Also 

# though L2 is declared in the enclosing scope, this scope 

# is global, and so no further enclosing scope is examined. 

# 

# Contrast with reference to name L2 in LocalPList L3 below. 
PList L2; 

PList Gl .LI ; # OK. Refers to LI in Gl . 

U Error. G3 is not really nested inside Gl . Since G3 

# is global, it is really declared at an outermost level, 

# and so G1.G3 is meaningless. 
PList G2.G3.L3; " ' 

} 

LocalPList L3 
{ 

# OK. Refers to G2.L2. The enclosing global scope is G2 

# and the name L2 is declared in G2. 
PList L2; 

} 



WO 2005/114235 PCT7JP2005/009813 

146 

[00384] All pattern list file names and pattern file names are required to be unique 
across the test plan using them. 

[00385] A pattern list reference can refer to a pattern list defined either before or 
after the reference in the same file. 

[00386] Recursive and mutually recursive pattern list definitions are not permitted. 
While there is nothing in the pattern list file syntax to prevent the user from creating such 
definitions, the parser will flag an error when it detects such conditions. Note that there is 
some cost associated with the detection of such conditions. The user will be able to 
switch off the check if s/he can assume the responsibility of guaranteeing that the input 
space is free from mutually recursive definitions. 

GlobalPList Gl 
{ 

LocalPList L2 
{ 

LocalPList L3 
{ 

# Error. L2 runs L3 which runs L2. 

# This is a recursive reference to L2 
PList L2: 



} 

} 



} 



PList G2; 



GlobalPList G2 
{ 

# Error. G1.L2 runs L3 which runs G2 which runs 
G1.L2. 

# This is a mutually recursive reference to Gl .L2. 
PList G1.L2; 

} 

[00387] The syntactic description of patterns and pattern lists allows for options to 
be specified on them. In general options are vendor specific. The syntax allows for any 
pattern or pattern list to have a number of options specified, each with a number of 
parameters. In we describe some supported options that will be recognized by most 
vendors. 
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[00388] The dynamic (i.e., execution) semantics of pattern trees is described in 
after defining a pattern execution sequence. 

E2. Patterns 

[00389] Figure 6 illustrates a pattern compiler 602 and a pattern loader 604 
5 according to an embodiment of the present invention. The user-defined contents of a 
pattern are available in a pattern source file 606, which is a plain text file. A pattern 
compiler will be responsible for compiling a source file into a module-specific format 
suitable for loading on the tester hardware; this latter file will be referred to as the pattern 
object file. The following are the general attributes: 

10 1 . A Pattern object is not creatable by the user; rather, the user always deals 

with pattern lists, which are collections of other pattern lists and/or patterns. 
A pattern list object creates, owns and maintains the pattern objects 
contained within it, while making them accessible to the user if necessary. 

2. A pattern is uniquely named within a test plan, i.e., no two patterns within 
1 5 the test plan can have the same name. The name of a pattern is distinct 

from the name of the file containing it. The pattern file name is the one 
used in the pattern list file to refer to a pattern, while the actual name of the 
pattern is defined in the pattern file. 

[00390] In an embodiment of the invention, in general, a single DUT (device- 
20 under-test) might be connected to tester modules from different vendors. This has 
implications for the entire pattern compile-load-execute chain. The main ones are 
described in this section. 

E3. Pattern Compilation 

[00391] A pattern compiler 602 thus needs to target a specific site configuration (in 
25 terms of the vendor-specific digital modules used). For the rest of this discussion, the 

term "module" will be used to refer to a digital module, as an example. In order to allow 
the integration of modules 608 from different vendors into the system, the following 
procedures are preferred: 

1 . Each module vendor will be responsible for providing its own module- 
30 specific pattern compiler 610, in the form of a dynamically loadable library 
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or separate executable. This compiler library/executable will provide, at 
the very least, a well-known compileQ function that takes as arguments 

a. an array of (one or more) pattern source file pathnames, 

b. the Pin Description file name, 
5 c. the Socket file name, 

d. an optional directory pathname specifying the destination of the 
compiled object, 

e. an optional array of string name/value pairs that allow the 
specification of any vendor-specific parameters (that can be ignored 

1 0 by other vendors). 

2. The pattern source file will accommodate two different types of sections: 

a. a "common" section that will contain information accessible to (but 
not necessarily used by) all compilers, and 

b. one or more optional vendor-specific sections, each identified by 
1 5 unique vendor codes, for information usable by specific vendors' 

compilers. 

3. A vendor's compiler will not directly create a pattern object file. Instead, 
the tester will provide for a pattern object "metafile'''' 612, managed by an 
Object File Manager (OFM) 614, which is part of the pattern compiler. 

20 The pattern compiler may be located on the computer acting as the system 

controller, or offline, e.g., on a network to which the system controller is 
connected. The "pattern object file" referred to so far in abstract terms is 
actually this object metafile. The object metafile will be named the same 
as the pattern source file, with the source file extension replaced by the 

25 object file extension. The OFM will provide an application programming 

interface (APIs) to read and write this file. The object metafile will have 
provisions for storing 

a. common header information, 
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b. module-specific header information, including information 
identifying the corresponding module and the location of pattern 
data for the module, 

c. module-specific pattern data, organized as required by the module 
5 vendor, and capable of being interpreted by the module vendor. 

[00392] The OFM APIs will allow a module vendor's compiler to write module- 
specific header information and data into the object metafile. Note that this layout of the 
object metafile allows the pattern data to be organized on a per-module basis, even in the 
case where two or more modules in the targeted site are identical. 

1 0 [00393] Note that additional vendor-supplied configuration information might be 

needed by pattern compilers to facilitate the generation of module-specific hardware 
loading information that can take advantage of efficient data communications such as 
direct memory access (DMA). 

E4. Pattern Load for a Module 

1 5 [00394] Each module vendor will be responsible for providing its own pattern 

loading mechanism 615, following the general procedure. The pattern object metafile 612 
of a module 608 stores module-specific data in different sections 616. The vendor 
implementation will use the OFM APIs for accessing the relevant module-specific 
sections from the pattern object metafile. The tester framework will be responsible for 

20 calling each module's load method in turn to load module-specific data to a module from 
the appropriate section of the metafile. 

E5. Pattern Files 

[00395] It is possible to have each compiler vendor specify entirely different plain 
text formats for patterns, which, in fact, might indeed be necessary in most cases. 

25 However, in general, for a cycle-based testing environment, where coherent and identical 
semantics across modules are necessary for every vector, a shared, generalized syntax for 
the pattern file is not only desirable, but may be necessary. This shared syntax is what 
will be specified for the "common" section in the pattern source file. In fact, for the 
majority of cases, it is envisioned that the "common" section is the only section (besides 

30 header information) that will be required in the pattern file, and every vendor's compiler 
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will work with only that section. This section presents rules for the pattern file that all 
compilers should be able to interpret. The pattern file will be organized as follows: 

flle_contents 

versioninfo pattern _defmitions 

5 versionjnfo 

Version version-identifier '; ' 

pattern definitions 

pattern _definition 

10 pattern jiefinitions pattern_definition 

pattern_definition 

mainjieader '{' mainsection '} ' 
mainjieader '{' mainjsection vendor jections '} ' 
subrheader '{' subr_section '} ' 
15 sabrjieader '{' subr_section vendor ^sections '}' 

mainjieader 

MainPattern identifier 

main_section 

CommonSection '{' common_contents 
20 main_section_domains '} ' 

common _contents 

timing_reference timing jnap_reference 

timingj-eference 

Timing file-name ';' 
25 timing jtiapj-eference : 

TimingMap file-name '; ' 
main_section_domains : 

main_section_domains main_section_domain 

main section domain 
30 main_section_domain 

Domain domain jiame '{' main_section_contents '} ' 

domain_name 

identifier 
main section contents : 
35 main_section_contents main_section_content 

main_section_content 
main_section_content : 

label_spec main jpattern_spec 

main _pattern_spec 

40 label_spec 

label':' 

label 

identifier 
main _pattern_spec 

45 main_operation capture jnask Jlag '{' 

vectors _and_waveforms '} ' 
main_operation : /* empty V 
common_operation 



WO 2005/114235 PCT/JP2005/009813 

151 

jal_op 
jsrjyp 
jsrcop 
jsc_op 

5 exit op 

common_operation 

idxiop 

idxinop 

jecop 

10 jechop 

jffj>P 
jffij>P 
jniop 
ldin_op 

1 5 nop_op 

pause_op 
sndc_op 
sndtop 
stfi_op 

20 sti_op 

stps_op 
wait_op 

/* 

* Instructions specific to the MAIN Patterns 
25 */ 

jsrjyp 

jsrc_op 

30 jsc op 

jal_op 



JSR identifier 
JSRC identifier 
JSC identifier 
JAL identifier 



exit_op 

35 EXIT 

/* 

* Instructions common to both MAIN and SUBR Patterns 

*/ 

idxi_op 

40 IDXI 24-bit number 

idxin_op 

IDXIn index-register 
JEC identifier 
JECH identifier 
JFF identifier 



jcc_op 

45 jechop 

jffj>P 
jffijiP 



PCT/JP2005/009813 

152 





JFFI identifier 


ini ov 






.HVT iHpwti'fipv 


Idifi on 








HOT) f)T) 






NOP 


pause op 






PAUSE 


sndc op 






SNDC 8-bit number 


sndt op 






SNDT 8-bit number 


stfi ov 






STFI 24-bit number 

kJ A -I. J. .£> J Li Lb lltAlllUCrl 


stiop 






STI 24-Z>/7 wM/wAer 


stps_op 






STPS 


wait_op 






WAIT 


capture jnask Jlag : /* empty */ 




capture jnask Jlag CTV 




capture jnask Jlag MTV 




capture jnask Jlag MATCH 



vectors _and_waveforms : /* empty */ 

vectors _and_waveforms vector 
vectors _and_waveforms waveform 

vector 

vector declaration '{' vector _data '} ' 
vector _declaration 

Vector 
V 

vector_data 

vectordatum 
vector_data vector _datum 

vector_datum 

pinjiame '=' 'vector-value ';' 
pin name '=' identifier ';' 

waveform 

waveform_declaration '{' waveform_data '} ' 

waveform _declaration 

Waveform 
W 

waveform_data 

waveform datum 
waveformjdata waveform _datum 
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waveform datum 

waveform-table-pin-group-name '=' identifier ';' 

pinjiame 

identifier 

5 vendor sections 

vendor sections vendor_section {} 
vendor section {} 

vendor section 

VendorSection '{' vendor jection_contents '}' 

1 0 subrjieader 

SubrPattern 

subrjsection 

CommonSection '{' common _contents 
source jselectionjable subr _section_domains '} ' 
15 CommonSection '{' common_contents 

subr_section_domains '}' 
subr 'section domains : 

subr section domains subr section domain 

subr_section_domain 
20 subr _section_domain 

Domain domain ' name '{' subr_section_contents '}' 
source _selectionJable : 

SourceSelectionTable '{' source _selector_definitions 

'}' 

25 source _selector_definitions: 

source_selector_definitions 
source _selector_definition 

sour ce_selector definition 

3 0 source _selector_definition: 

SourceSelector source _selector_name '{' 
source jnappings '}' 
source selector _name : 
identifier 

35 source jnappings 

source jnappings source jnapping 
source jnapping 

source mapping 

pinjiame '=' source ';' 

40 source 

MAIN 
INVERTJMAIN 
SUBR 

INVERTJSUBR 

45 subr_section_contents : 

subrjsection jjontents subr _section_content 
subr jsectionjzontent 
subr section jzontent : 

label jspec subr jpatternjspec 
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subr jpatternspec 
subr _pattern_spec 

subr_operation capturejnask Jlag '{' 
vectors andwaveforms '}' 
5 subr - operation : /* empty */ 

common _operalion 

rtnop 

stss_op 

/* 

10 * Instructions specific to the SUBR Patterns 

V 

rtnop 

RTN 

stss_op 

15 STSS identifier 

[00396] The following are the descriptions of undefined non-terminals used above: 

1 . version-identifier : A sequence of one or more characters from the set [0- 
9.], where the first character must be a digit. 

20 2. identifier : A sequence of one or more characters from the set [a-zA-Z_0- 

9], where the first character must be from the set [a-zA-ZJ. 

3. vendor-section-contents : Arbitrary text that is meaningful only to a 
vendor-specific compiler. 

4. file-name A valid Windows file name (must be enclosed in double quotes 
25 if any white-spaces are contained in the file name). Note that this should 

be a simple file name, i.e., it should not have a directory component. 

5. waveform-table-pin-group-name : A sequence of one or more characters 
from the set [a-zA-Z_0-9], where the first character must be from the set 
[a-zA-ZJ. This variable is declared elsewhere and holds the name of the 

30 waveform-table that is common to a group of pins. 

6. 24-bit number :A valid decimal number up to a maximum of 1 67772 1 5 . 

7. 8-bit number :A valid decimal number up to a maximum of 256. 

8. index-register :A valid decimal number. In one embodiment of a module 
this can have a value [1-8]. 
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9. vector : This is similar to the Vector statement in STIL. Note that this 
refers to signal names and signal groups names, making it necessary for the 
compiler to have access to the Pin Description file. 

10. waveform-time-reference : A sequence of one or more characters from the 
5 set [a-zA-Z_0-9], where the first character must be from the set [a-zA-ZJ. 

[00397] Pattern files will support comments, which are meant to be ignored by a 
pattern file compiler. Comments will start with the '#' character, and extend to the end of 
the line. 

[00398] The following points should be noted with reference to the constructs in 
1 0 the pattern file's header and "common" sections: 

1 . The pattern-name item specifies the name that will be associated with the 
Pattern object that the pattern file contains the data for. This gets carried 
over to the header in the corresponding pattern object metafile. 

2. The waveform-time-reference is the name for a particular waveform-and- 
15 timing definition that would be defined externally to the pattern file, in the 

Timing file. The specification of a waveform-time-reference in the pattern 
file would bind that particular name (for a waveform-and-timing) to all 
subsequent vectors, until another waveform-time-reference were 
encountered. 

20 3. The operand for a subroutine call (e.g., JSR and JSRC) is a string that 

should either be a pattern-spec label previously encountered in the same 
pattern file, or a pattern-spec label in an externally defined subroutine 
pattern. This operand will ultimately be resolved for the purposes of 
loading/handling subroutines. The labels for subroutine call operands are 

25 required to be unique across the system. 

[00399] Note that while waveform-time-reference names could be anything that is 

syntactically correct, due to specific hardware implications the waveform-time-reference 
names may need to be restricted to a previously known, well-defined set (which, for 
added readability, can be optionally mapped by the user to user-chosen names, the 
30 mapping presented in an optional file). 
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[00400] Also note that the pattern and waveform-time-reference source files should 
provide initial configuration data for all DUT channels which have connections to 
physical tester channels. If subsequent data is omitted for any DUT channel, the pattern 
compiler will "pad" the pattern data to hold output from the initial level. 

Pattern File Example 

[00401] A simple example of a MAIN Pattern source file will help illustrate the 
usage. 

# 

# Filename : goodl.pat 

# 

Version 1.0 ; 

# 

# Main Pattern definition: 

# 

MainPattern goodl 
{ 

CommonSection 
{ 

MacroDef defaultDataVal (XXXXXXXX) 
MacroDef noplnstr (NOP) 
MacroDef labell (Label 1 : ) 

MacroDef jnilnst (JNI) 

# 

# Timing Specifications 

# 

Timing "productionTiming.tim"; 

TimingMap "productionTimingOpenSTARMap.tmap" ; 

# 

# Default Domain Cycles 

# 

Domain default 
{ 

# 

#label: instruction {Vector/Waveform Data} 

# 

NOP { V { DATA = SdefaultDataVal; CLK = 1 ;} 

W { DATA = wfsl; CLK = wfsl; } } 

JAL myAPG { V { DATA = 00000000; } } 
JSC mySCAN { V { DATA = 10101010; } } 
JSRC mySubroutine { V { DATA = 01010101; } } 
JSR myAPG { V { DATA = 001 1001 1; } } 
STI 100 { } 
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labZero: NOP { V { DATA = 0000001 1 ; } } 

JNI labZero { V { DATA= 11111100; } } 
IDXI 3000 { V { DATA = 10101010; } } 
IDXIn 3 {V {DATA = 01010101; } } 

$labell NOP { V { DATA = $defaultDataVal; } } 

IDXI 2000 { V { DATA = 10101010; } } 
NOP { } 

EXIT { V { DATA = LLHHLLHH; } } 

} 

} 

} 

[00402] Another example illustrating a SUBROUTINE pattern source file is 
illustrated below. 



# Subroutine Pattern mySubrPatl definition: 

# 

SubrPattern mySubrPatl 

{ 

CommonSection 
{ 

# 

# Timing Specifications 

# 

Timing "productionTiming.tim"; 

TimingMap "productionTimingOpenSTARMap.tmap" ; 

# 

# Source Selection Specifications 

# 

SourceSelectionTable 

{ 

SourceSelector SrcSelDef 
{ 

DATA=SUBR; CLK=SUBR; DATA=SUBR; 

} 

SourceSelector SrcSelOne 
{ 

DATA=MAIN; CLK=MAIN; 

} 

} 

# 

# Default Domain Cycles 

# 

Domain default 
{ 
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#- 



#label : instruction { Vector and Waveform Data setups } 

# 

STI 100 { Vector { DATA = 00000000; } } 
5 IDXI 3000 { Vector { DATA = 00001 111;}} 

IDXIn 3 { Vector { DATA = 001 1001 1 ; } } 
Slabell NOP { Vector { DATA = LLHHLLHH; } } 

NOP { Vector { DATA - LLXXXXXX; } } 

NOP { Vector { DATA = LLHHXXXX; } } 

1 0 JNI Labell { Vector { DATA = LLHHLLHH; } } 

STSS SrcSelOne { Vector { DATA = LHLHLHLH; } } 
RTN { Vector { DATA = LLXXXXXX; } } 

} 

} 

15 } 

[00403] Summary information from the main header and common section in the 
pattern source file is stored in the main header in the object metafile. The summary 
consists of information that is typically required for quick extraction to aid pre-load 
resolution of addresses, etc., or to aid in datalogging. Since the semantics of the common 
20 section are exactly the same for all compilers, every compiler will be capable of providing 
the same summary information, and the first compiler writing the metafile will store this 
information. The following is the information that will be stored: 

1 . The pattern source file name. 

2. The type of the pattern as declared in the source file. 
25 3. The version information from the source file. 

4. A list of all the waveform-and-timing names used in the pattern source 
file's common section. 

5. A map of all subroutine references to (relative) vector addresses in the 
pattern source file's common section. 

30 6. A map of all label references to (relative) vector addresses in the pattern 

source file's common section. 

7. General bookkeeping information: vector count, instruction count, etc. 

[00404] ' The open architecture test system requires both pattern and pattern list files 
to have explicit, and different, extensions. For pattern files, this applies to both plain text 
35 source and compiled object files. This is viewed as a convenience to the user to quickly 
identify the file type visually in a directory listing, etc., as well as allow associations to be 
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The pattern list file parser will expect filenames with 



Plain text pattern source file: .pat 

Compiled pattern obj ect metafile: .pobj 

5 Pattern list file: .plst 

[00405] The user can override these default values, e.g., through tester environment 
variables or setup options. 

[00406] The tester will require the definition of the following "environment" 
variables for file search paths in at least one of the environment configuration files 
10 described in: 

Tester JMTLIST_PATH: For pattern list files. 
TesterPATSRCPATH: For pattern source files (optional). 

Tester_PATOBJ_PATH: For pattern object metafiles. 

[00407] Note that if the optional environment/setup variable 
1 5 Tester_P ATSRC_P ATH is not defined, it will be assumed to be the same as 
Tester_PATOBJ_PATH. In general, it would be more efficient to not define 
Tester_PATSRC_PATH rather than define it with the same value as 
Tester? ATOBJ_P ATH. 

E6. Software Representation 

20 [00408] A Pattern object is not created by the user; rather, the user always deals 
with Pattern List objects, which are collections of other pattern lists and/or patterns. A 
Pattern List object creates, owns and maintains the pattern objects contained within it, 
while making them accessible to the user. A pattern list object in the user's test program 
is associated with a pattern list file on disk, which contains the actual definition of the 

25 pattern list. The definition of a pattern list provides an explicit name for the pattern list, 
and identifies an ordered list of patterns and/or other pattern lists through file name 
associations. This section describes the software representation of pattern lists and 
patterns, as a prelude to understanding how they are manipulated in the tester framework. 
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[00409] A single test site in the test system (and, by extension, the test plans in it) 
can be associated with multiple top-level pattern lists. However, there is only a single 
execution context for test plans at any given time. Since a top-level pattern list defines an 
5 execution sequence for the patterns referred to (hierarchically) by it, the active execution 
context is the one corresponding to the currently selected top-level pattern list. Note that 
this does not imply that only the patterns contained in a single pattern list can be loaded 
on the hardware at one time; rather, the set of patterns that are required to be loaded on 
the hardware to make an execution sequence viable must always be a subset of all the 
1 0 currently loaded patterns . 

Pattern Trees 

[00410] Intuitively, it is felt that a way to represent a top-level pattern list is by 
some sort of a tree data structure. Figure 7 illustrates an embodiment of an ordered 
pattern tree of the invention, assuming that the pattern list A is the top-level pattern list 

15 Pattern Tree Information Content 

[00411] The following information will be stored at every node of the pattern tree: 

1 . The name of the entity (pattern-list or pattern) associated with that node. 

2. The type of the definition source. For a leaf (pattern node), this will 
always be a pattern file; for an intermediate (pattern list) node, this could 

20 be either "top-level file" (for top-level pattern list definitions) or 

"embedded in file" (for nested pattern-list definitions). 

3. The last modification timestamp of the file on disk the node is associated 
with. 

[00412] The following additional information will be stored only in intermediate 
25 (pattern list) nodes: 

1 . Execution options (if any) set on the pattern-list object represented by that 
node — i.e., its object options. 
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2. The execution options (if any), set on each child reference inside the 

pattern list definition represented by that node — i.e., the reference options, 
for each of its children. 

[00413] Thus, the collection of nodes encountered on the unique path from the root 
5 to an intermediate node, and the sequence in which they are encountered, contain all the 
information necessary to determine the combined, effective, execution options represented 
by that node . The execution options of a pattern are determined by the effective 
execution options of its immediate parent, combined with the reference options its 
immediate parent might have for it. 

1 0 [00414] It should be noted here that while the pattern list parser is in the process of 
creating the pattern tree, certain execution options might require initial storage of values 
simply as strings, since the context of their use might not be resolved until later. An 
example of such an option is a "mask" option, which specifies pin mask information: 
pattern lists are not associated with Socket information, and hence, pin mask options (pin 

15 and group names) are stored as strings, to be resolved prior to loading. 

[00415] The following additional information will be stored only in leaf (pattern) 
nodes: 

1 . All (possibly transitive) references to subroutines called by that pattern, 
both external and internal, organized as an execution tree. 

20 [00416] Of course, all pattern nodes will additionally have access to — and might 
choose to cache — all the pattern file summary information available in the object 
metafile common header. 

Handling Pattern List Modifications 

[00417] Changes made to the contents of a pattern list conceptually affect all 
25 references to that pattern list. The following rules, which apply as appropriate to pattern 
objects as well as pattern list objects, will be used to manage such changes: 

1 . A change made to the contents of a pattern list file on disk will be 
propagated through the test system only on a loadQ command being 
executed on that pattern list (or on any other pattern list that references that 
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one). In other words, the pattern list hierarchy in software will always 
reflect the one currently loaded on the hardware. 

2. The user will be able to set a mode that will defeat the checks made during 
load time to synchronize pattern lists with their disk file sources; this will 
allow quicker/safer operation in production mode. 

Pattern Tree Navigation 

[00418] The top-level pattern lists associated with a test site (and, by extension, 
with a test plan for that site) have public (global) scope. The system provides APIs to 
navigate the pattern tree representing a top-level pattern list so that users can get access to 
individual nodes and sub-trees. 

E7. Pattern List Dynamics 

[00419] Earlier the static rules of Pattern Lists were described. A description of the 
dynamic (execution) rules of pattern lists is now presented. 

[00420] The pattern tree is essential for general pattern management. For example, 
the starting point for a pattern load sequence is a call to the loadQ method on the pattern 
tree currently associated with the site or test plan. However, a pattern tree does not 
operate in isolation. A fully initialized pattern tree will be used to create the following 
two framework objects: 

[00421] 1 . A top-level pattern list defines a Pattern Execution Sequence for 

the patterns. It describes how such an execution sequence can be derived from the pattern 
tree corresponding to that top-level pattern list. For example, the pattern execution 
sequence corresponding to the pattern tree A shown in Figure 7 is {q, s, t, q, r, q, u, u, v} . 
The Pattern Execution Sequence is conceptually an ordered list reflecting the execution 
sequence described through the pattern tree. The framework establishes and maintains 
any necessary navigation links between pattern tree nodes and corresponding entries in 
the Pattern Execution Sequence. 

[00422] 2. The Pattern Set, which is simply a list of all the unique patterns 
(including subroutines) in the pattern tree. This is thus the list that will be used to 
determine the individual patterns that should be loaded on the hardware. The framework 
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establishes and maintains any necessary navigation links between pattern tree nodes and 
corresponding entries in the Pattern Set. The Pattern Set for the pattern tree of Figure 7 is 
(q, s, t, r, u, v) (it is assumed that none of the patterns in pattern list A contain any 
subroutine calls): 

[00423] Note that both the Pattern Execution Sequence and the Pattern Set can 
always be derived from the pattern tree; however, it would often make sense to cache 
them, after initial construction, for as long was viable. 

Pattern List Execution Options 

[00424] As shown above, each pattern list declaration (preceding its definition) or 
pattern list/pattern reference entry can be followed by a number of execution options. 
Pattern list execution options modify the runtime execution of pattern lists. To allow 
future extensions, the names (and optional values) for these options will be treated simply 
as strings by the pattern list file parser of the pattern compiler, to be interpreted by a 
particular version as appropriate. Tester prescribes a set of options and their 
interpretations, described below. However, vendors can extend the set of options. In 
order to allow a parse-time validation of option syntax, the pattern list file parser could 
read an information file for a particular version. Such an information file could also be 
used to specify whether a particular version at all supports the specification of execution 
options. 

[00425] For versions that support a set of execution options, the following general 
rules will govern their use. In order to understand these rules, it is useful to visualize the 
hierarchical collection of pattern lists/patterns as an ordered tree. 

1 . Intrinsic options set on pattern list definitions (i.e., in the "local-pattern- 
list-declaration, global-pattern-list-declaration" productions in the file are, 
in effect, direct option settings on the corresponding Pattern List object in 
the user's test program. They thus apply to all references to that pattern 
list object, and are referred to as object options. 

2. Referential options set on references to pattern lists/patterns (i.e., in the 
"pattern-entry" and "pattern-list-entry" productions in the file limits the 
scope of the options to a specific path in the hierarchy — the path 
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(established by the declaration order of pattern lists/patterns) that leads 
from the root of the tree to the reference under consideration. These are 
thus options on specific object references (and not on the objects 
themselves), and are referred to as reference options. 

5 3. The effective option settings for any list/pattern in the collection hierarchy 

(established by the declaration order of pattern lists/patterns) are a 
combination of the object and reference options encountered along the path 
from the root of the tree to that list/pattern. The specific combination 
mechanism (e.g., set union, set intersection, or any other conflict resolution 
1 0 algorithm) is a property of the option itself. 

[00426] Note that a consequence of the above rules — and the fact that there is no 

facility to set execution options on a pattern definition in a pattern file — is that there is 
no direct rule to set options which apply to all references to a pattern. The mechanism for 
achieving this is to use a single-pattern pattern list. 

1 5 [00427] The tester specifies a certain set of pattern list execution options that 

modify its burst behavior, and that modify its execution sequence, 

[00428] When an execution sequence for a pattern list is submitted to the hardware, 
the hardware produces a burst. A Burst is the execution of a sequence of patterns directly 
by the hardware, without any involvement from the software. A Burst Discontinuity is a 
20 position in an execution sequence where a prior burst is terminated, and a new burst is 
started. 

[00429] One of the objectives of the pattern management software is to provide the 
hardware with the execution sequences that it needs to produce a burst on. By default, a 
pattern tree yields an execution sequence, which if submitted to the hardware will result in 
25 a single burst. This behavior can however be modified by the use of options on the 
pattern list. Thus, the use of options result can result in burst discontinuities. 

[00430] Furthermore, users will sometimes require a prologue or epilogue pattern 
to be run before or after every pattern or every burst. This modifies the execution 
sequence to be submitted to the hardware. 
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[00431] During the creation or modification of the Pattern Execution Sequence 
object, the framework has all the information necessary to determine, and report if 
required, breaks in pattern bursts resulting from the combination of execution options 
specified and the particular execution sequence embodied by the pattern tree. While 
5 doing this, it might need to investigate the hardware capabilities of the modules in the 
system. For example, one hardware implementation allows four stored configurations for 
pin masks, of which two (0 and 3) are used for default masked (to support Mask This 
Vector, MTV) and unmasked operation. The user is thus allowed two different global 
pin-mask configurations without breaking burst mode. 

10 [00432] Note that if a module vendor does not support pattern list implementations 
in hardware, the vendor's processing of the Pattern Execution Sequence would result in 
individual execution of all patterns in the execution sequence. In both Site-Compatible 
and Site-Heterogeneous systems, the burst capability of sites would be limited by the 
"lowest common denominator". The tester provides for a certain default set of options 

1 5 and their parameters is described below. Each option is specified by stating: 

Whether it is Intrinsic (i.e. associated with a definition with the Global or Local 
keyword) or Referential (i.e. associated with a reference with the Pat or PList 
keyword). Intrinsic options apply at the point of definition and at every reference, 
but referential options apply only at the reference they are associated with. 

20 Furthermore, an option is said to be Inherited by Children if the option is assumed to 
apply recursively to all statically (syntactically) or dynamically (semantically by being 
referenced) nested patterns or pattern lists. 

[00433] Below is the list of options. Every compliant vendor will interpret these 
options as specified. 

25 1. Mask <pin / pin group> 

. Intrinsic when applied to GlobalPList, LocalPList 
Referential when applied to PList, Pat. 
Inherited by children. 

This pattern list will always have the compare circuits of the pins referred 
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to by the indicated pin or pin group disabled. Sometimes, hardware 
limitations may result in burst discontinuities. 

2. BurstOff 

Intrinsic when applied to GlobalPList, LocalPList 
5 Referential when applied to PList, Pat. 

Not inherited by children. 

This pattern list will always execute in the non-burst mode. This option is 
not inherited by children, but the BurstOffDeep option (below) is inherited 
by children. 

10 3. BurstOffDeep 

Intrinsic when applied to GlobalPList, LocalPList 
Referential when applied to PList, Pat. 
Inherited by children. 

This pattern list will always execute in the non-burst mode. This option is 
15 inherited by children, but the BurstOff option (above) is not inherited by 

children. Note that the BurstOffDeep option cannot be turned off by a 
child. 

4. PreBurst <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 
20 Inherited only by child nodes having no burst options specified. 

The indicated pattern is to be prefixed to all bursts within this pattern list. 
The PreBurst pattern occurs just before every burst that is started due to 
this pattern list node. The option is not applied when already within a 
burst which has a PreBurst option that is the same pattern. 

25 5. PostBurst <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 

Inherited only by child nodes having no burst options specified. 
. The indicated pattern is to be suffixed to all bursts within this pattern list. 

The PostBurst pattern occurs just after every burst that is started due to this 
30 pattern list node. The option is not applied when already within a burst 

which has a PostBurst option that is the same pattern. 
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6. PrePattern <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

The indicated pattern is to prefixed to all patterns within this pattern list. 

7. PostPattern <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

The indicated pattern is to be suffixed to all patterns within this pattern list. 

8. Alpg <alpg object name> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

The named ALPG object stores relevant information such as slow speed 
APG register settings, read latency, immediate data registers, address 
scramble, data inversion, data generators, etc. 

9. StartPattern <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

The pattern list will start executing at the first occurrence of the 
StartPattern in its execution sequence. 

10. StopPattern <pattern> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

The pattern list will stop executing at the first occurrence of the 
StopPattern in its execution sequence. 

1 1 . StartAddr <vector offset or label> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

• This must be accompanied by a StartPattern option. The pattern list will 
start executing at the StartAddr in the first occurrence of the StartPattern in 
its execution sequence. 
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12. StopAddr <vector offset or label> 

Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

This must be accompanied by a StopPattem option. The pattern list will 
5 stop executing at the StopAddr in the first occurrence of the StopPattem in 

its execution sequence. 

1 3 . EnableCompare_StartPattern <pattern> 
Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

1 0 Pattern comparison will commence at the first occurrence of the indicated 

pattern. 

14. EnableCompare_StartAddr, EnableCompareJStartCycle 
Intrinsic when applied to GlobalPList, LocalPList 

Not inherited by children. 
15 This must be accompanied with EnabelCompare_StartPattern. Indicates 

the address or cycle within the pattern where pattern comparison is to start. 

1 5 . EnableCompare_StopPattern <pattern> 
Intrinsic when applied to GlobalPList, LocalPList 
Not inherited by children. 

20 Pattern comparison will complete at the first occurrence of the indicated 

pattern. 

16. EnableCompare_StopAddr, EnableCompare_StopCycle 
Intrinsic when applied to GlobalPList, LocalPList 

Not inherited by children. 
25 This must be accompanied with EnableCompare_StopPattern. Indicates 

the address or cycle within the pattern where pattern comparison is to 
complete. 

17. • Skip. 

Referential when applied to PList, Pat. 
30 Not inherited by children. 

Causes a pattern or the entire subsequence dominated by a pattern list to be 
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skipped. This will also cause skipping of all options at the root of this 
pattern list sub-tree. It is as if this pattern sub-tree were not there for 
execution purposes. 

Pattern List Burst Control 

[00434] As described earlier, when an execution sequence for a pattern list is 
submitted to the hardware, the hardware produces a burst of a sequence of patterns, 
without any involvement from the software. A Burst Discontinuity is a position in an 
execution sequence where a prior burst is terminated, and a new burst is started. The 
PreBurst , PostBurst, BurstOff and BurstOffDeep options control where the burst 
discontinuities occur, as described in the option list above. PreBurst and PostBurst options 
determine burst discontinuities subject to certain additional rules described below: 

1 . When a parent list has PreBurst and PostBurst options, and the nested list 
has the same corresponding options, there is no burst discontinuity, and the 
PreBurst and PostBurst options of the nested list do not apply. There is 
only a single burst applying the PreBurst and the PostBurst of the parent 
list. 

2. Notice that when the nested list has no burst options, it is equivalent to 
having the same PreBurst and PostBurst options as the parent list by the 
description of these options. Consequently, nested lists with no burst 
options do not result in a burst discontinuity. 

3. If rule 1 above does not apply and there is a contribution to the pattern 
execution sequence from the start of the parent list to the start of the nested 
list, then there is a burst discontinuity at the start of the nested list. In this 
case the PreBurst and PostBurst of the parent list apply to this contribution 
to the pattern execution sequence from the parent list. The PreBurst and 
the PostBurst of the nested list apply to the nested list. 

4. If rule 1 above does not apply, and there is a contribution to the pattern 
execution sequence from the end of the nested list to the end of the parent 
list, then there is a burst discontinuity at the end of the nested list. In this 
case the PreBurst and PostBurst of the parent list apply to this contribution 
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to the pattern execution sequence from the parent list. The PreBurst and 
the PostBurst of the nested list apply to the nested list. 

5. If rule 1 does not apply, and there is no contribution to the pattern 

execution sequence from the parent list other than from the nested list, then 
5 the PreBurst and the PostBurst of the parent list do not apply. There is 

only a single burst applying the PreBurst and PostBurst of the nested list. 

[00435] Below are a few examples illustrating the effect of options on the 

execution sequence. To simplify, it is assumed that all the pattern lists are specified in a 
single file. 

10 [00436] Example 1: Use of BurstOff 

[00437] This example illustrates BurstOff and PreBurst. Of particular emphasis is 
that BurstOff causes patterns to run singly in bursts that are one pattern long. Hence the 
PreBurst option still applies. The input pattern lists are as below: 

Global A [BurstOff] [PreBurst pat_z] 
15 { 

Pat q; 
PList B; 
Pat r; 
Pat s; 

20 

Global C 
{ 

Pat t; 
PList D; 

25 }; 



30 



}; 



PList D; 
PList E; 



Global B 

{ 

Pat a; 

35 Patb; 

>; 



Global D [BurstOff] 
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{ 

Pate; 
Patd; 

}; 

5 

Global E 
{ 

Pate; 

10 }; 

The tree rooted at A may be represented in Figure 8. 

[00438] The execution sequence for this pattern is below. The | character indicates 

a burst break. This pattern list executes in 10 bursts, the first one having patterns z and q, 
and the last one with pattern e: 

15 zq|ab|zr|zs|t|c|d|c|d|e 

[00439] Note the following about this execution sequence: 

1 . Since the BurstOff option on A is not inherited by B, the patterns a and b 
in B operate as a burst. 

2. Since the PreBurst option on A is not inherited by B, the a and b in the 
20 burst by B is not prefixed by z. 

3. The prefix by z only happens for the patterns that are executed due to being 
direct children of a, namely patterns q, r and s. These patterns are executed 
singly as if in a burst that is only one pattern long due to A having the 
BurstOff option. The BurstOff requires patterns to be run individually in 

25 one-pattern long bursts. Hence, the PreBurst and PostBurst options still 

apply. 

4. Pattern list D has an intrinsic burst off option that causes its children c and 
d to execute singly. They do not inherit the PreBurst z from A. 

[00440] Example 2: Use of BurstOffDeep 



30 



[00441] This example illustrates the BurstOffDeep option. BurstOffDeep during 
pattern list definition affects nested definitions and referenced lists. However, PreBurst 
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and PostBurst options are not inherited by nested and referenced lists. The example uses 
the same patterns A, B, C, D, E as in example 1, but the options are different: 

5. Options on definition of A: [BurstOffDeep], [PreBurst z], [PostBurst y] 

6. No other options on any other node. 

[00442] The execution sequence is as below. As earlier, the | character indicates a 

burst break. 

zqy|a|b|zry|zsy|t|c|d|c|d|e 
Note the following about this execution sequence: 

1 . PreBurst and PostBurst are not inherited by B, C, D, E. 

2. BurstOffDeep is inherited by B, C, D, and E. 

Example 3: PreBurst and PostBurst Inhibition 

Suppose now the pattern list tree of Example 1 is considered, where the 

Options on definition of A: [PreBurst x] [PostBurst y] 
Options on definition of C: [PreBurst x] [PostBurst z] 
No other options on any other node. 

The execution sequence would be: 
xqabrstcdcdey 

The reasons why the "t c d" subsequence is not "x t c d z" are as follows: 

The first x is inhibited since it is equal to the pre-burst option x that is 
associated with the current burst in effect 

2. The last z is inhibited since the PostBurst z is not inherited to D, and there 
is no pattern that is generated from C to which the z can be appended. 

[00447] Example 4: Use of Skip 



[00443] 

[00444] 

options are: 

1. 
2. 
3. 

[00445] 



[00446] 

20 1. 



25 [00448] This example illustrates the effect of the Skip option on nested definitions 

and referenced lists. The example uses the same patterns A, B, C, D, E as in example 1, 
but the options are different: 
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2. 
3. 

[00449] 



[00450] 

1. 
2. 

[00451] 
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Options on definition of A: [Skip], [PreBurst z], [PostBurst y] 
Options on reference to r: [Skip] 
Options on definition of C: [Skip] 

The execution sequence is a single burst with no breaks as below: 
zqabscdey 

Note the following about this execution sequence: 
The nodes for r and C are skipped. 
There are no burst breaks at all. 

Example 5 : Use of Mask 



10 [00452] This example illustrates the effect of the Mask option and its effects on 
pattern and pattern list definitions and references. The example uses the same patterns A, 
B, C, D, E as in example 1, but the options are different: 

1 . Options on definition of A: [mask pinl_pin2], [PreBurst z] 

2. Options on reference of B: [mask pin3] 
15 3. Options on definition of B: [mask pin4] 

4. Options on reference of e: [mask pin5] 

5 . No other options on any nodes. 

[00453] The name "pinl_pin2" specifies a group which masks Pinl and Pin2. The 
names "pin3", "pin4" and "pin5" specify masking Pin3, Pin4and Pin5 respectively. The 
20 execution sequence is provided below, with | indicating the burst break. The numerals 
below each pattern indicate the pins that are masked during that pattern execution. 

zqabzrzstcdcd|e 
1111111111111 1 

2 222222222222 2 
25 3 3" 5 

4 4 



[00454] 



Note the following about this execution sequence: 
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1 . The vendor's hardware can only accommodate 2 mask blocks without a 
burst break. Until e is executed the two mask blocks are pins {1,2} and 
pins {1, 2, 3, 4}. When pattern e arrives with a different mask block of 
pins {1, 2, 5}, the hardware requires a burst break. 



5 [00455] Example 6: Use of Inherited Options and References 

[00456] This example illustrates that an inherited option at a definition does not 
apply when the definition is referenced. Consider the following example: 

Global A 
{ 

Global B [BurstOffDeep] 
{ 

Global C 
{ 

};"' 
}; 



PList C; 

}; 

Global D 

{ 

PList C; 

y> ; 

[00457] The BurstOffDeep option is inherited by C at its point of definition. 
However, it is not an intrinsic option, and so it is not applied to C at both its point of 
references. 



30 [00458] Example 7: PreBurst and PostBurst with Nested Lists 



[00459] Consider the following example: 

GlobalPList A [PreBurst x] [PostBurst y] 
{ 

Pat pi; 
35 

LocalPListB [PreBurst x] [PostBurst y] 

{ 

Pat p2; 



10 



15 



20 



25 
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} 

LocalPList C 
Patp3; 

LocalPList D [PreBurst x] [PostBurst z] 
Pat p4; 

LocalPList E [PreBurst w] [PostBurst y] 
Patp5; 

Patp6; 

} 

[00460] The execution sequence is: 

x pi p2 p3 y | x p4 z | w p5 y | x p6 y 

1 . Pattern p2 is in the same burst as pi because the PreBurst and PostBurst 
options of the nested list are specified the same as the parent. Pattern p3 is 
also in the same burst because these options are inherited the same as the 
parent. These options have at least one different member in the remaining 
nested lists, giving rise to burst discontinuities 

Timing 

[00461] The user interacts with the system primarily by defining the test setups 
using pattern files. The Timing File is used to describe the Timing of these patterns. This 
file requires other system files (e.g. Pin, SpecSelector) for underlying definitions to be 
resolved. Further the Spec-Selectors and Global definitions used to resolve various 
variables used in the Timing definition are encapsulated in a composite 
TestConditionGroup object. Higher-level files, such as the Test Plan file, in turn use this 
TestConditionGroup instance. 

[00462] The Test Plan File contains references to the TestConditionGroup object. 
The Pattern Source File makes references to the WaveformSelector components within a 
TimingMap object. The Timing objects itself references the Pin objects. Optionally the 
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Timing object might also reference a variable modulated by a SpecSelector object. These 
relationships are illustrated in Figure 9. 

[00463] The Pattern object within the Pattern-List specifies the name of the 
WaveformSelector object to use for a set of pattern characters. Also note that the Timing 
5 Map file is specified in the pattern. Patterns need not be compiled if this map is not 
changed. 

Version 1 .0; 
MainPattern 

{ 

10 CommonSection 



15 



25 



{ 



Timing = myGalxy.tim; 
TimingMap = myGalxyMap.tmap; 



Domain default 
{ 

NOP V {SIG=1;CLK>1;DATA=L; } W {§IG=wfsl; 
FASTCLK=wfsl; } 
20 NOP W {SIG=wfs2;} 

NOP V {SIG=L;} 
NOP V {SIG=0;} 



} 



Here we define the 
WaveformSelector 
component of the TimingMap 
to use for the pattern 
characters. 



[00464] The TestConditionGroup File objects import the Timing object to use and 
30 the TimingMap object to use. Each Test uses a TimingCondition instance derived from the 
TestConditionGroup object for that instance. Thus multiple Timing objects, which 
support the same set of waveform tables, can be stored in the tester framework and can be 
swapped as required. Similarly multiple Test Plan Files can share a common 
TestConditionGroup object. 

35 [00465] An example of a Test Plan description file illustrates the usage of the 
Timing object below. 

Import patlistl.plist; 
Import timl.tim; 
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Import tim2.tim; 
Import tmap 1 .tmap; 
TestConditionGroup timl jprod 
{ 

SpecSet = prodTmgSpec(min, max, typ) 
{ 

period = 10ns, 15ns, 12ns; 

} 

Timings 

{ t 

Timing ! = timl; I 
TimingMap = tmap 1 ; 

} 



Two Tests within a Test Plan 
using different timing objects 
defined earlier. 



} 

TestConditionGroup tim2_pro/ 
{ 

SpecSet = prodTmgSpectmin, max, typ) 
{ 

period = 10ns, 1 12ns; 

} 

Timings 
{ 



Timing = tim2; 



} 



TimingMap = tmapl; 



TestCondition timl_prod_typ 

TestConditionGroup = timl_prod; 
Selector = typ; 

TestCondition tim2_prod_max 

TestConditionGroup = tim2_prod; 
Selector = max; 



Test FunctionalTest MyFunctionalTestSlow 

PListParam =patlistl; 
TestConditionParam = timl_prod_typ; 



Test FunctionalTest MyFunctionalTestFast 



PListParam =patListl; 
TestConditionParam = tim2_prod_max; 
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[00466] The Timing object defines various waveforms on a per pin basis. The pins 
used in the Timing file and the Timing Map file need to be defined appropriately in the 
Pin definition file. 

[00467] The Timing object can use SpecificationSet objects to define values within 

the waveform objects. Though the Timing object can include hard-coded values for 
various attributes it is usually the case that users have various attributes be assigned 
values using variables. These variables in turn can depend on SpecificationSet objects. 
An example of this usage is illustrated below. 

Version 1.0; 
Timing basicjfunctional 
{ 

Pin SIG 

{ 

Waveform Table wfs 



This variable, which defines the 
edge placement, is defined 
elsewhere and is dependent on a 
SpecificationSet. 




{ 1 4 Ufgtt lei : D@t_te D; Z@45ns;} } 

}; 

}; 

Pin CLK 

{ 

WaveformTable wfsl 
{ 

{ 0 {U@20ns; D@40ns; }}; 

}; 

}; 

} 

[00468] The SpecSelector is defined as illustrated below. 



SpecificationSet prodTmgSpec( min, max, typ) 
{ 

. t_le = 10ns, 14ns, 12ns; 
t_te = 30ns, 34ns, 32ns; 

} 

[00469] ' The changing.of the tuning used by changing the spec is illustrated in the 
example below. 
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TestCondition prodTmpJyp 

{ 

TestConditionGroup = prodTmgSpecx. 



SpecSelector ==typ; 



} 



TestConditionGroup prodTmp_max 
{ 

TestConditionGroup = prodTmgSpec; 
SpecSelector f max; | -< 



This timing uses the 
"typical specification in 
the SpecSelector. 



This timing uses 
the max 

specification in the 
SpecSelector. 



}; 

F2. Mapping to the Timing Components of a tester 

[00470] Two components of a tester module are directly involved with the 
generation of wave shapes and their associated tunings. The two modules are the Pattern 
Generator (PG) and the Frame Processor (FP). A simplified block diagram illustrating 
the wave shape formatting and die timing generation by the Frame Processor within the 
open architecture test system architecture is illustrated in Figure 1 0. A brief description 
of the generation of waveforms is given below. 

[00471] The Pattern Generator 1002 generates a timing set which is common for all 
the pins in the module. This timing set is called the Global Timing Set (GTS). There are 
three modes in which the Pattern Generator can be set up. These three modes affect the 
number of bits that can be used to describe the GTS. In addition these settings also 
impact the number of bits used to select a bank and whether the Capture This Vector 
(CTV) and Mask This Vector (MTV) bits are set or not. To instruct the tester to capture 
the results of this vector, the user uses the CTV flag in the Pattern file. Similarly the user 
uses the MTV flag in the pattern to instruct the tester to mask the results of the current 
vector. This is illustrated in Table 1 below. The Pattern Generator 1002 is also responsible 
for the generation of Waveform Characters (WFC). WFCs are generated on a per pin 
basis. The tester module uses a fixed number of bits to describe the WFCs. 



GTS bits 


GTS in a 
Bank 


GTS Bank 


CTV 


MTV 


8bits 


256 


4 


NO 


NO 


7bits 


128 


8 


YES 


NO 
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6bits 


64 


16 


YES 


YES 



Table 1 



[00472] The tester module provides a Frame processor 1 004 per pin. Each Frame 
Processor contains a Timing Set Scrambler (TSS) 1006, which has a total depth of up to 
1024 in this example. The TSS 1006 can be partitioned into a number of banks 1008 
5 depending on the mode of the Pattern Generator as described earlier and illustrated in 
Figure 10 where 16 banks of 64 entries per bank are being used. The TSS is provided so 
as to allow more flexibility in the ability to define Waveform Tables for each pin. In the 
"FP" mode the TSS outputs a Timing Set using 2 bits. Thus the TSS will generate a total 
of four distinct physical Timing Sets per pin. These Timing Sets are referred to as the 
1 0 Local Timing Sets (LTSs). 

[00473] The Frame Processor 1004 combines LTS and WFC and creates an index 
1010 into the Waveform Memory 1012 and Timing Memory 1014. In the "FP" mode the 
5 -bit value is split up with 2 bits being generated by the LTS and 3 bits being generated 
by the WFC. Thus the depth of the physical Waveform Memory and Timing Memory is 
15 32 deep per pin though a maximum of 4 physical Timing Sets may be used. The 

Waveform Memory contains the enabled timing edges that form the wave shapes. The 
timing values for the enabled edges are obtained from the Timing Memory, Thus, the 
Frame Processor formats wave shapes. 

Mapping Methodology 

20 [00474] The methodology is to map all the WaveformTable blocks on a per pin 
basis to LTSs in the tester. If tester hardware supports 4 LTSs, the user can define a 
maximum of 4 WaveformTable blocks. Each WaveformTable block can have a maximum 
of n waveform definitions for the tester digital module. ' 

[00475] The Timing-Map file provides a mapping of Logical WaveformSelectors 
25 defined in the- Timing-Map block to the WaveformTable for the module in open 
architecture test system. In this case the tester supports up to 256 Logical 
WaveformSelectors. In open architecture test system system , the Logical 
WaveformSelectors map directly to the GTSs. The Pattern compiler depends on both the 
Timing-Map and the Timing blocks to be able to compile the pattern files. However if the 
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waveform characters in the WaveformTables of the Timing block are unchanged or the 
WaveformSelector mappings in the Timing-Map block are unchanged, there is no need to 
re-compile the pattern. 

[00476] Example Using this Mapping Methodology 

5 [00477] To illustrate the mapping into a tester Digital Module the following 

assumptions are made: the Frame Processor is set to the FP mode; and CTV and MTV 
bits are set so total number of GTS bits is 6 and the total number of Timing Bank Selector 
bits is 4. 

[00478] Each WaveformTable defined in the Timing block is mapped to a distinct 

10 LTS within the Timing file. This is done on a per-pin basis. Thus WaveformTable seql is 
mapped to LTS 1. In the case of the "SIG" pin all 8 possible waveform entries are used up. 
However the "CLK" pin requires a single waveform entry and thus uses up a single row in 
the Waveform memory (WFT) and the Waveform Timing memory (WTM). 

[00479] The mapping of the first 2 physical waveforms of the "SIG" pin is 
1 5 illustrated in Figure 1 1 . As this WaveformTable maps two waveform characters that need 
separate configurations of the edges, we end up allocating two entries in the Waveform 
memory (WFT) 1 1 12 and the Waveform Timing memory (WTM) 1114. The shape of the 
waveform is stored in the WFM and the timing details are stored in the WTM. One 
embodiment of the module has a total of 6 timing edges Tl, T2, T3, T4, T5 and T6. 
20 These map directly to the Events El, E2, . . . defined in the waveforms within a Edge 
Resource section of the Timing block. If more than 6 events are defined in the Timing 
block and this is used with a the above module, it will result in an error. 

[00480] In the example of Figure 1 1, the first waveform character "0" uses Timing 
Edge Tl to program the "Force Down" or "D" event, which occurs at time 10ns into the 
25 cycle. Timing Edge T2 is also used to generate a "Force Down" or "D" event at time 30ns. 
Finally Timing Edge T3 is used to generate a "Force Off or "Z" event at time 45ns. 

[00481] The second waveform character "1 " uses Timing Edge Tl to program the 
"Force Up" or "U" event, which occurs at time 10ns into the cycle. Timing Edge T2 is 
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also used to generate a "Force Down" or "D" event at time 30ns. Finally Timing Edge T3 
is used to generate a "Force Off or "Z" event at time 45ns. 

[00482] . In this fashion, the WFCs are mapped into the WFM memory and WTM 
memory of the Frame Processor. The final setup of Waveform Memory WFM of LTS1 
5 for pin "SIG" is illustrated in Table 2 below. 
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Index 


(WFC) 


TlSet 


TlReSet 


T2Set 


T2ReSet 


T2Drel 


T2Dret 


EXPH 


EXPHZ 


T3Set 


T3ReSet 


T3Drel 


T3Dret 


T4Drel 


T4Dret 


EXPL 


EXPHZ 


0 


0 




1 




1 
















1 










1 


1 


1 






1 
















1 










2 


d 




1 


1 


















1 










3 


u 


1 






1 
















1 










4 


L 






























1 




5 


H 














1 




















6 


m 






























1 




7 


n 














1 





















Table 2 
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[00483] The final setup of Waveform Timing Memory WTM of LTS 1 for pin 
"SIG" is illustrated in Table 3 below. 



Index 


(WFC) 


i — l 

H 


H 


EXPH 


<r> 
H 




EXPL 


0 


0 


10ns 


30ns 




45ns 






1 


1 


10ns 


30ns 




45ns 






2 


d 


I2ns 


32ns 




42ns 






3 


u 


I2ns 


32ns 




42ns 






4 


L 












I7ns 


5 


H 






I7ns 








6 


m 












I5ns 


7 


n 






I5ns 









Table 3 

5 
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[00484] The "CLK" pin uses up a single waveform and thus the WFM and WFT 
for this pin are very simple. The final setup of Waveform Memory WFM of LTS1 for the 
"CLK" pin is illustrated in Table 4 below. 



Index 


(WFC) 


TlSet 


TlReSet 


T2Set 


T2ReSet 


T2Drel 


T2Dret 


EXPH 


EXPHZ 


T3Set 


T3ReSet 


T3Drel 


T3Dret 


T4Drel 


T4Dret 


EXPL 


EXPHZ 


0 


1 


1 






1 


























1 




































2 




































3 




































4 




































5 




































6 




































7 





































Table 4 

5 [00485] The final setup of Waveform Timing Memory WTM of LTS2 is illustrated 
in Table 5 below. 



Index 


(WFC) 


i — ( 

H 


H 


EXPH 


m 
H 




EXPL 


0 


1 


20ns 


40ns 










1 
















2 
















3 
















4 
















5 
















6 
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7 

Table 5 

[00486] The TimingMap block explicitly maps out the WaveformSelectors to the 

Waveform tables of the Timing block. For a tester system this boils down to setting up the 
Timing Set Scrambler (TSS) memory. The TSS basically contains a mapping from the 
5 GTS to the LTS that holds the settings. The TSS setup for our example for pin SIG will 
look like Table 6 below. 



GTS 


LTS 


0 (wfsl) 


1 


1 (wfs2) 


1 


2 (wfs3) 


2 


3 (wfs4) 


1 


4 (wfs5) 


3 


5 (wfs6) 


1 






N(wfsl) 


1 






255 





Table 6 



[00487] Finally after the TSS and LTS setup mappings are resolved, the Pattern 
1 0 Compiler can use this information to program the pattern with the correct waveform table 
(LTS) and the correct waveform character to use. Thus our example pseudo-pattern 
considering only pin "SIG" is illustrated in Figure 1 1 . Note that this compilation has no 
dependency on the Timing block and only depends on the Timing-Map block. 

G. Tester Operation 
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[00488] This section describes the basic operation of the tester operating system 
(TOS). The activities considered in this section are: 

system initialization 
Test Plan loading 
5 Pattern loading 

Running a Test Plan 
Running an individual Test 
System Initialization 

10 [00489] In order to initialize the system in one embodiment, certain assumptions 
must be satisfied, and certain conditions must be met. The following sub-section lists 
these. 

Preconditions 

[00490] Copies of the relevant system software components have a central store, 
1 5 whose location is known to the System Controller. This may be on the System Controller 
itself, or on another system with a network mounted directory (or known to the SYSC via 
another mechanism) — whatever the mechanism, before the system can function, all 
software must be made available to the System Controller for use. This software 
includes: 

20 vendor hardware control (i.e., module software) DLLs, 

standard or user test class DLLs, and 
user test plan DLLs. 

[00491] The system module configuration file is available on the System Controller. 
25 Recall that this file allows the user to specify the physical configuration of the tester, e.g., 
the physical location and type of each module in the system chassis, as well as the names 
of the module software DLLs. 
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[00492] The system configuration file is available on the System Controller. Recall 

that this file contains the list of Site Controllers in the system, as well as a map of Site 
Controller hostnames to Switch Matrix input port addresses. 

[00493] Site controllers have a service called the Site Configuration Manager 
5 (SCM) running. This service is responsible for determining what hardware is installed in 
each slot, by a process termed "hardware discovery". It is also responsible for 
participating in the system initialization process with the System Controller. Note that the 
Switch Matrix operation protocol dictates, in one embodiment, that the SCM on a single 
Site Controller, with Switch Matrix input port connection address 1, should always be 
10 used to configure the Switch Matrix connections to the modules. Recall that this 
"special" site is denoted as SITEC-1. 

[00494] The System Controller is responsible for providing each Site Controller's 

SCM with its Switch Matrix connection address. 

[00495] Each Site controller's SCM is capable of starting a process called the Test 
1 5 Plan Server (TPS). The Test Plan Server on each Site Controller is ultimately responsible 
for containing and executing the user's test plan (or test plans, in the case where a single 
Site Controller is running tests on multiple DUTs). 

Initialization Phase I: System Validation 

[00496] Once the above assumptions and preconditions have been satisfied, system 
20 initialization first proceeds with a system validation step as follows: 

1 . The System Controller reads the system and module configuration 
files to initialize the user-specified view of the system. 

2. Using the specified system configuration information, the System 
Controller verifies that the specified Site Controllers are alive, 

25 reachable, and ready (i.e., have SCMs running). Any error during 

this verification step will cause a system error to be raised, and 
initialization to be aborted. 
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3. The System Controller then instructs the SCM service at SITEC-1 
to configure the switch matrix to have access to all hardware 
modules, and requests it to perform hardware discovery. 

4. The SCM service at SITEC-1 polls all available module slots 
(known hardware locations) for {vendor, hardware} tuples and 
generates a map of {vendor, hardware} tuples to slots. At 
conclusion, this poll has thus identified the entire set of {vendor, 
hardware, slot} bindings that exist in the complete system. The 
results of this poll are sent to the System Controller. 

5. The System Controller verifies that the results of the above 
hardware discovery step match the user-specified configuration in 
the module configuration file. Any error during this verification 
step will cause a system error to be raised, and initialization to be 
aborted. 

6. The System Controller then loads a default environment (such as 
search paths for module DLLs, pattern lists, patterns, test plan 
DLLs, test class DLLs, etc.) from the environment setup file(s) at 
well-known location(s). 

7. The System Controller ensures that all identified module software 
DLLs exist. If one is not available on the System Controller, it is 
retrieved from the central store, if possible; otherwise, a system 
error is raised, and initialization is aborted. 

Initialization Phase II: Site Configuration (Optional) 

[00497] Site configuration, or site partitioning, involves the software-level 
assignment of the available system hardware modules to different sites (i.e., to service 
multiple DUTs). Recall that site-partitioning information is provided in a socket file. 

[00498] The tester system allows site (re-)partitioning to be performed both as part 
of a test plan load (since each test plan is associated with a particular socket), and as an 
independent user-callable step. In the latter case, the user initiates the site partitioning by 
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providing a socket file that is used solely to partition the system. This is especially useful 
during system initialization in the case of multi-DUT testing where each site tests a 
different DUT type. However, this step is optional during the initialization stage, and the 
user can choose not to have it performed, opting instead to allow a test plan load to 
partition the system appropriately. 

[00499] Whatever the means chosen to effect site partitioning (by an independent 
call or implicitly through a test plan load), the mechanism is the same. This mechanism is 
described below. 

1 . Given the socket, the System Controller first determines whether 
the currently existing system partition is compatible with the socket, 
or whether a re-partitioning is necessary. The default partition 
during initialization is one in which all available modules are 
connected to SITEC-1. The remaining steps below are performed 
only if re-partitioning is needed. 

2. The System Controller sends a configuration message to each Site 
Controller SCM to re-configure itself with the number and 
identities of DUT sites that are enabled for it under the new socket. 
Note that this is a general procedure, and handles the case where 
the number of DUT sites controlled by a Site Controller is one. 
The new socket information is also conveyed to the SCMs. 

3. Each SCM stops the running TPS, if any, and starts a new one, 
initializing it with the new socket, and the number and identities of 
DUT sites that are enabled for it under the new socket. 

4. The System Controller determines which sites need what subsets of 
the required system modules. While doing this, it also prepares 
hardware slot information for the sites. The net result is, for each 
site, a list of slots versus module DLLs assigned to that site. This 
site-specific list will be denoted as the Site Module DLL Slot List 
(SITE-MDSL). 
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5. The System Controller provides the appropriate SITE-MDSL, as 
well as the necessary module DLLs, to each SCM. Each SCM in 
turn makes this information available to the newly-started TPS. 

6. The System Controller then requests SITEC-1 to configure the 
Switch Matrix for the proper site-to-slot connections, that is, for 
site-partitioned operation. 

7. The TPSs on sites 1 through n load the DLLs specified in their 
SITE-MDSL. Each of these DLLs has a function named initialize() 
which takes an array of slot numbers. The TPS calls initialize() 
with the appropriate slot lists for that module type. On any 
malfunctions at this point, a system error is raised, and initialization 
is aborted. The initialize() method does the following: 

a. Creates concrete classes based on a standard interface 
LXXXModule. For example, a DLL associated with a digital 
module will create a single IPinModule-based object to service 
each slot it is associated with. 

b. Creates concrete classes based on interface IResource, 
one for each "resource unit" in the module. Again, for a digital 
module, each IPinModule-based object will create ITesterPin-based 
objects for all pins in the collection of slots occupied by digital 
modules. 

8. The TPSs on sites 1 through n then call getXXXModule() on each 
loaded module DLL to retrieve module contents information. 

9. Each call to getXXXModule() returns a 
<VendorHWType>Module class object as an IModule pointer 
(e.g., AdvantestPinModule). Each such IModule pointer is 
cached by the TPS, which makes these available to framework/user 
code. Note that the collection of IModules, IResources, etc. 
are persistent (at least for the lifetime of the TPS). 

10. Once the above steps are complete, the TPS starts to listen() on its 
assigned (well-known) port. This signals to the System Controller 
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that the TPS is "ready" to begin normal (i.e., site-partitioned) 
operation. 

Test Plan Load 

[00500] This section describes the steps by which a user Test Plan DLL is loaded 

on a Site Controller (for single or multiple DUT testing). 

[00501] Once system initialization (and optionally, initial site partitioning) has been 
completed, user test plans can be loaded. The loading of a user test plan on a Site 
Controller proceeds as follows: 

1 . The System Controller first loads the test plan DLL into its own 
process space, querying it for its associated socket file and its DUT 
type identifier. This information is used to identify the site(s) 
running this test plan, and hence, the Site Controller(s) that this test 
plan would be loaded on. 

2. The System Controller then uses the socket information associated 
with the test plan to initiate the re-partitioning process as outlined 
above. 

3. The System Controller extracts the list of test class DLLs used by 
the test plan from the test plan DLL, and once the System 
Controller has verified that the TPS is ready to begin normal (i.e., 
site-partitioned) operation, sends the test class DLLs, and, finally, 
the test Plan DLL itself, to the appropriate TPS. 

4. The TPS calls LoadLibraryO to load it into its process space. It 
calls a well-known function on the DLL to create as many 
TestPlan objects as the number of sites (i.e., DUTs) it is servicing. 

5. The TPS initializes the TestPlan object(s) with the necessary tester 
framework objects. During initialization, the TPS loads the 
appropriate DLLs for the test classes used by the TestPlan 
object(s) into the process space, and creates the test class instances. 
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6. The TPS sets up the communications channel to/from the System 
Controller to the TestPIan object(s). 

7. The System Controller communicates with the TPS, and builds its 
proxies for the TestPIan object(s). 



[00502] The concludes the successful load of the user's Test Plan on a Site 
Controller. 

Running a Test Plan 

[00503] The method to execute all tests in a test plan according to the pre-defined 

flow logic is as follows: 

1 . The user's application transmits a RunTestPlan message to the 
TPS. The TPS sends an ExecutingTestPlan message to all 
connected applications. The TPS then calls executeQ on the Test 
Plan. 

2. Testing multiple DUTs with a single Site Controller is performed 
using multiple threads on that Site Controller, one per DUT. Each 
thread runs a different, independent instance of the same 
TestPIan object. Since, in this case, module control software 
DLLs might be shared across DUTs, the module commands for 
hardware communication are required to take a DUT identifier 
parameter. 

3. The TestPIan object iterates over each test in its collection 
(alternatively, tells its Flow object to process each test according to 
the flow logic), calling preExecQ, executeQ, and postExecQ. 

4. As each test executes, status messages are sent back to all 
connected applications. 
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[00504] A user may wish to execute a single test in a test plan instead of all tests. 
For single test execution, the method is as follows. 

1 . User application transmits a RunTest message to the TPS; the TPS 
sends an ExecutingTest message to all connected applications. 
The TPS then calls executeTest() on the Test Plan, specifying the 
test to run. 

2. The Test Plan object executes the specified test by calling 
preExecQ, execute(), and postExec() on that test object. 

3. When the test executes, it sends status messages back to all 
connected applications. 

[00505] There are at least two benefits achieved by the disclosed method for 

developing a test program. First, the method separates the complexity of system 
programming from the test plan developers by describing the test plan in a language that 
is closer to the problem domain that the test plan is intended to address. Second, the 
method enables test engineers to identify errors in a test plan in an earlier stage of the test 
program development, which may reduce the development time of the test programs and 
the corresponding DUTs being tested. 

[00506] One skilled in the relevant art will recognize that many possible 
modifications and combinations of the disclosed embodiments may be used, while still 
employing the same basic underlying mechanisms and methodologies. The foregoing 
description, for purposes of explanation, has been written with references to specific 
embodiments. However, the illustrative discussions above are not intended to be 
exhaustive or to limit the invention to the precise forms disclosed. Many modifications 
and variations are possible in view of the above teachings. The embodiments were 
chosen and described to explain the principles of the invention and their practical 
applications, and to enable others skilled in the art to best utilize the invention and various 
embodiments with various modifications as are suited to the particular use contemplated. 
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CLAIMS 

What is claimed is: 

5 1 . A method for developing a test program for a semiconductor test system, the test 
system including at least one test module for applying at least one test to a device-under- 
test according to the test program, comprising: 

describing a test plan file in a test program language (TPL), wherein the test plan 
file describes at least one test of the test program; 
1 0 describing a test class file in a system program language (SPL) and a 

corresponding pre-header file of the test class file in the TPL, wherein the test class file 
describes an implementation of the at least one test of the test program; and 

generating the test program using the test plan file, the test class file and the pre- 
header file. 

1 5 2. The method of claim 1 , wherein the system program language is C/C++. 

3. The method of claim 1 , wherein generating the test program comprises: 
compiling the test plan file by a TPL compiler to form a derived test plan file. 

described in the SPL; and 

compiling the pre-header file by the TPL compiler to form a header file described 
20 in the SPL. 

4. The method of claim 3, wherein compiling the test plan file comprises: 
translating the test plan file from the TPL to the SPL; and 
validating the test plan file using the pre-header file. 

5 . The method of claim 3, wherein compiling the pre-header file comprises : 

25 inserting in the header file parameters described in a parameters section of the pre- 

header file; and 

inserting in the header file source code referenced in a template section of the pre- 
header file. 

6. The method of claim 3, further comprising: 
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compiling the derived test plan file by a SPL compiler to form a test plan object 
file, wherein the test plan object file references the header file; and 

compiling the test class file by the SPL compiler to form a test class object file, 
wherein the SPL compiler uses the header file to form the test class object file. 

7. The method of claim 6, further comprising: 

linking the test plan object file and the test class object file to form the test 
program, wherein the test program is executable by the semiconductor test system. 

8. A pre-header for generating a test program for a semiconductor test system, the 
pre-header comprising: 

a parameters section for specifying at least one attribute of the test program; and 
a template section for inserting source code into a header file of the test program. 

9. The pre-header of claim 8, wherein the at least one attribute of the test program 
relates to a pattern list and a test condition. 

10. The pre-header of claim 9, wherein the pattern list comprises at least one of the 
following parameters: 

cardinality; 
trace level; 
member name; 
set function; and 
parameter description. 

1 1 . The pre-header of claim 9, wherein the test condition comprises at least one of the 
following parameters: 

cardinality; 
trace level; 
member name; 
set function; and 
parameter description. 

12. The pre-header of claim 8, wherein the template section comprises: 
class name; 
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import declarations; 
parameter array types; 
parameter attributes; 
parameter functions; and 
5 parameter function implementations. 

13. The pre-header of claim 8, wherein the pre-header is used by a test program 
language (TPL) compiler to generate a header file, and wherein the header file is 
described in a system program language (SPL). 

14. The pre-header of claim 13, wherein the header file is used by a SPL compiler to 
10 generate a test class object file, and wherein the header file is referenced by the SPL 

compiler to generate a test plan object file. 

1 5 . The pre-header of claim 8, wherein the pre-header is used to support user-defined 
tests in the test program. 

16. A method for validating a test program for a semiconductor test system, the test 

1 5 system including at least one test module for applying at least one test to a device-under- 
test according to the test program, comprising: 

describing a test plan file in a test program language (TPL), wherein the test plan 
file describes at least one test of the test program; 
describing a pre-header file in the TPL; and 
20 validating the test plan file using the pre-header file. 

1 7. The method of claim 1 6, wherein the pre-header file comprises : 

a parameters section for specifying at least one attribute of the test program; and 
a template section for inserting source code into a header file of the test program. 

18. The pre-header of claim 17, wherein the at least one attribute of the test program 
25 relates to pattern list and test condition. 

19. The method of claim 16, wherein validating the test plan file comprises verifying 
semantics of the test plan file. 



WO 2005/114235 PCT/JP2005/009813 

198 

20. The method of claim 16, wherein validating the test plan file further comprises 
verifying test entity attributes of the test plan file. 

2 1 . The method of claim 1 6, wherein validating the test plan file further comprises 
verifying functional calls and their corresponding parameters of the test plan. 

5 22. A semiconductor test system, comprising: 

at least one test module for applying at least one test to a device-under-test; 

a controller for receiving a test plan file, a test class file and a corresponding pre- 
header file of the test class file, wherein the test plan file describes the at least one test in a 
test program language (TPL), and wherein the test class file describes an implementation 
10 of the at least one test in a system program language (SPL); 

means for compiling the test plan file and the pre-header file to form a derived test 
plan file and a header file respectively; and 

means for generating a test program using the test class file, the derived test plan 
file, and the header file. 

15 23. The semiconductor test system of claim 22, wherein the pre-header file 
comprising: 

a parameters section for specifying at least one attribute of the test program; and 
a template section for inserting source code into the header file of the test program. 

24. The semiconductor test system of claim 23, wherein the at least one attribute of 
20 the test program relates to a pattern list and a test condition. 

25. The semiconductor test system of claim 24, wherein the pattern list comprises at 
least one of the following parameters: 

cardinality; 
trace level; 
25 member name; 

set function; and 
parameter description. 

26. The semiconductor test system of claim 24, wherein the test condition comprises 
at least one of the following parameters: 



WO 2005/114235 



PCT7JP2005/009813 



199 

cardinality; 
trace level; 
member name; 
set function; and 
5 parameter description. 

27. The semiconductor test system of claim 23, wherein the template section 
comprises: 

class name; 
import declarations; 
1 0 parameter array types; 

parameter attributes; 
parameter functions; and 
parameter function implementations. 

28. The semiconductor test system of claim 22, wherein the system program language 
15 is C/C++. 

29. The semiconductor test system of claim 22, wherein means for compiling the test 
plan file comprise: 

means for translating the test plan file from the TPL to the SPL; and 
means for validating the test plan using the pre-header file. 

20 30. The semiconductor test system of claim 22, wherein means for compiling the pre- 
header file comprise: 

means for inserting in the header file parameters described in a parameters section 
of the pre-header file; and 

means for inserting in the header file source code referenced in a template section 
25 of the pre-header file. 

3 1 . The semiconductor test system of claim 22, wherein means for generating the test 
program comprise: 

means for compiling the derived test plan file to form a test plan object file, 
wherein the test plan object file references the header file; and 
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means for compiling the test class file to form a test class object file, wherein the 
the header file is used to form the test class object file. 

32. The semiconductor test system of claim 31, further comprising: 

means for linking the test plan object file and the test class object file to form the 
5 test program, wherein the test program is executable by the semiconductor test system. 
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